We are working on making our eCommerce site accessible for screen readers and have a conflict about pricing. Our categories and product pages list multiple dollar amounts when a product is discounted:
Original Price (in strikethrough)
Discounted Price (what customer will actually pay)
Savings (orig - discounted)
Is there any standard way to communicate all of this information for visually impaired users? We don't want to omit anything but also want to avoid making the product listing too long to traverse.
Currently, VoiceOver reads our pricing as "price, $9.99" [TAB] "sale, $7.99" [TAB] "savings, $2"
We are considering relabeling this all to a single statement so that the user doesn't have to tab through each price. "was $9.99, now on sale for $7.99, save $2"
Would the above work, or is there a more standardized way to communicate this?
As far as I know, there is no real standard telling precisely how you should present the pricing information.
It's up to you to find the best formulation for your particular case.
As long as everything is clearly stated in text, it should be fine.
The thing you must absolutely avoid is giving (implicitly) an information only by its visual formatting.
For example, making a price striketrough without explicitly saying somewhere that this is the original price and that there is currently a discount creates an accessibility problem for screen reader users and those who may not see well the striketrough.
So basicly you are on the right track by indicating everything textually.
Now, personnally by experience as a screen reader user myself, starting from your example, I would say:
Give first the discounted price before the original price, because what I'm going to pay is the information I'm looking for in priority.
Be smart and give the complete information in a single concise sentance. Example: "$7.99 instead of $9.99, saving $2".
Don't give the saving first, as it can be easily perceved as an excessive marketing manipulation. Example: "Save 20%! $10 instead of $12" vs. "$10 instead of $12, save 20%!"
#QuentinC has some good advice on the order of information (most important first - the price you're going to pay) but one thing that bothers me in the OP is why the user is going to tab through all the prices. Are the prices interactive elements?
Or perhaps this is just a terminology issue. I think by tab, you really mean swipe right to move the VoiceOver focus.
One thing to consider if you decide to make it one big sentence, it makes it a little harder to parse all that information. A VoiceOver user can change their rotor to "words" and then swipe up/down to navigate a word at a time in order to hear the info, but it might not be the best user experience to force them to do so. But the fact that you're providing all this information is really the important part, so kudos to you.
Also, VoiceOver stops at element boundaries when you're swiping right so if you have something like:
<div>
<span>hello</span>
<s>there</s>
<span>world</span>
</div>
You're going to hear "hello" swipe right "there" swipe right "world".
If you just want to hear "hello there world" with one swipe, then you'll need the undocumented (and thus not officially supported) "text" role.
<div role="text">
<span>hello</span>
<s>there</s>
<span>world</span>
</div>
As a side note, even though <s> and <del> are semantic elements, their meaning is not conveyed to screen readers. One way to handle that is documented in a "Short note on making your mark (more accessible)".
Would the above work, or is there a more standardized way to communicate this?
You should avoid to disturb the attention by introducing too many informations to the screenreader.
I am not saying this is a standard solution, but a solution you have to consider is just to ignore the old price using aria-hidden:
$7.99 <div aria-hidden="true">($9.99)</div>
This way a screenreader user will only ear the new price, and really gain in accessibility. As the text is strike-through, I won't think that WCAG would require a speech alternative here.
Related
I'm trying to improve screen reader support on our webapp, but I'm struggling a bit with what the best practice is for our buttons. Our current pattern looks something like this
If I focus on the button, should the screen reader say...
...Choose file, required?
...Upload personal letter: choose file?
...Upload personal letter: choose file. Allowed filetypes: doc, docx. Required?
We're currently going for the more talky version, but our team has limited experience with screen reader users and how they're used, so a push in the right direction would be very helpful. Thank you. :)
There is no real rule. It should be fine as long as indications are clear enough for the user.
In fact, it depends a lot on how you are used to your screen reader, Internet and your device in general:
Advanced users tend to prefer shorter labels and may be annoyed by longer ones.
Beginners may not understand if the label is too concise
Beginners may also be overflowed if the label gives too much extra information, or don't understand if the vocabulary is too technical
Screen readers have many options allowing you to decide what to say and what not to say. For example, Jaws calls that verbosity and there are 3 general levels that are further customizable.
Sadly, on the web, you can't determine the selected level, nor adapt the markup knowing that this element is only spoken in advanced or intermediate mode (this can be further highly customized anyway)
So the best is probably the middle option: be not too concise, but not too verbose either.
I'm a screen reader user myself; as an advanced user, regarding your propositions; I would say:
The second gives more confidence on what you expect exactly than the first one. If there are several files to upload, for example a cover letter + a CV + a photo, it's very important to have the information, so that there is less risk to mess up, i.e. upload the photo in the CV field.
If there are several fields with the same label that are labelled the same, it's hard to know which is which.
Indicating the allowed file types and other requirements of that kind is very good, but it is probably better placed outside the label.
Remember that the entire label is spoken again each time you tab into the field. If there are 5 fields with the same information, or if the form is complicated and you must go back and forth several times, it's annoying to hear many times the same.
So, I would go for a variation on the second one: "upload personal letter, required".
And indicate somewhere else in the page technical constraints like file type, size, etc. because it's still a very good idea.
Note that the "required" information can be left out from the label if you put the required and aria-required attributes on the field. It's the recommanded way to indicate that a field is required.
Tl;DR: Keep it concise.
If you want to convey some additional info like allowed file types, sizes, "no viruses please" etc., do not put this on the button itself. Prefer, for example, aria-describedby and make a separate control describing all those things, visually connected to the button (say, to the right of it).
We, I mean screen reader users, often navigate by items and do other weird stuff like invoking list of all buttons on the page (even Narrator nowadays started supporting such things), so if the button label is too long, it would be irritating too shortly.
I'm trying check my website by http://achecker.ca
and in potential problems section, I have very much problems...
Exactly I mean this problem:
Success Criteria 2.4.4 Link Purpose (In Context) (A)
Check 19: Link text may not be meaningful.
Every link on my main page is listed here as a problem...
What wrong could be in links like that:
PARTY
News title
<img src="images/ico/ico10.gif" alt="games">
The testing tool http://achecker.ca/ shows this potential problem for all links, even for this one (which is as meaningful as it can get):
<a href="http://stackoverflow.com/questions/38933605/achecker-link-text-may-not-be-meaningful" rel="external">
Stack Overflow question: <cite>Achecker Link text may not be meaningful</cite>
</a>
It’s documented at http://achecker.ca/checker/suggestion.php?id=19, where it says under "Short Description":
All a (anchor) elements that contains [sic] any text will generate this error.
This page also gives hints how to determine/check if your links pass or fail.
The relevant WCAG 2.0 guideline is 2.4.4 Link Purpose (In Context).
The potential problems listed by AChecker are typically not problems at all, but a human has to make that confirmation.
Regarding the meaningfulness of your links, think about someone giving you the text of a link on its own and asking you to define its meaning. Is the word "Party" meaningful. This word can be interpreted in multiple ways.
When navigating with a screen reader (if one is blind) listening to links in the sequence they appear on the page, nearby links can add meaning to single words like this. Will the links prior give the word Party the meaning of a "festive occasion" or perhaps a "political party", or even an "interested party," etc.. "News titles" is probably meaningful enough. "Games," the alt text for the image, could also be interpreted in multiple ways. Is there context (surrounding links) that give more specific meaning to the word "games?" Olympic games, video games, playing games, etc. If the context does not add meaning, then the link text itself needs to be adjusted to specify which meaning of the word is being used.
All links will be listed as "potential" problems by AChecker, requiring a human to make a decision on whether the text effectively describes the link's destination or function.
Potential problems are those the checker cannot identify with any certianty. Anywhere there is meaning involved, AChecker will identify potential problems. Known, Likely, and Potential problems are described on the first page of the Handbook, linked from the top right corner of AChecker.
http://achecker.ca/documentation/index.php?p=checker/index.php
Quote from the handbook:
AChecker identifies 3 types of problems:
Known problems: These are problems that have been identified with certainty as accessibility barriers. You must modify your page to fix these problems;
Likely problems:These are problems that have been identified as probable barriers, but require a human to make a decision. You will likely need to modify your page to fix these problems;
Potential problems: These are problems that AChecker cannot identify, that require a human decision. You may have to modify your page for these problems, but in many cases you will just need to confirm that the problem described is not present.
The key here is that they might not be meaningful.
I think they are being flagged because they only have 1-2 words in and so the tool is asking you to verify that the link text is good.
The kind of thing that should actually be considered as a failure of this rule are links that simply read "click here" or "more info", because they aren't actually explaining where the link goes. Other things to watch out for are multiple links with the same text but different destinations, and links with no text at all.
When I want to have a message show when a user mouse overs an object, and lately I just use the title attribute on my html tags since it's simple and automatically doesn't go off screen.
Question: Is using the title attribute is a bad thing to rely on for a tool-tip?
Ignoring the fact you can't customize it, I'm curious about functionality over using a custom made tool-tip (such as how the standard user interacts with it). A specific web-comic I read, for example, uses the title attribute to add a witty comment / factoid when you hover over it. Yet not many people seem to know about it.
As such it seems a title might be good for a comment, or even saying author of a picture, but is it good for a true simply tool-tip?
Considering for a 'real' tool-tip you need usually 1-2 extra elements, css (and depending how you set it up, possibly some inline style for placement), and possibly even java-script, is the title attribute bad to use since (again) it cannot be customized, is often a small off-topic detail about the element, and only appears after a set amount of time.
Note: If it helps (food for thought), my current situation that brought this question on, is I like when a site has something like [?] for you to hover over to find more details without shoving them into the page, thus keeping it simple.
Also, I learned html from w3schools, and they never mention the title attribute, so not really sure what they are intended / should be used for. (and yes, mentioning w3schools part was a (bad) attempt at getting sympathy)
And I find this question kind of weird to ask considering SO uses them quite a bit, but feel free to assume I know nothing about it as... well... I really don't)
The title attribute (#title), should not be used.
Every browser does their own thing with the #title, even though it looks the same.
For people who just use the keyboard, they cannot get the information in #title.
People accessing the site from a mobile device, cannot get the information.
Some, but not all assistive technology can get the information in the #title
some allows it to be read after enabling it. Which not many people (users) know about.
other technology simply ignores the link text and reads the #title only.
Ex of 4.2:
Delete your account
This will read:
Are you sure? Link
Further Reading: PG: Title attribute
First of all,hats off to your question. Good thinking. I guess we people [I'm speaking about amateur coders like me] needn't develop a big site or rather lack that expertise. We simple need to keep getting our things done in an optimized manner. Therefore, similarily, I have also encountered almost every script using title for tooltips. Guess,it's the simple way to tackle it. Moreover, as long as the tooltip is attractive, isn't slow, and caters our need: its all good.
The title attribute is simple, and simplistic. It is not reliable. No tooltip mechanism really is, but the tooltips generated by title attributes have rather poor usability: tiny font size, problems with line control, timed disappearance, no way (to normal users) to make it stay put so that you can actually read it even if you are a slow reader. Besides, there is normally no hint to the user about the availability of a tooltip.
I use "read more" at the end of paragraph just for reminder for user same like P.T.O
Why it's problematic?
You have to understand that many screen reader users don't wait for the whole page to be read to them. They use keyboard shortcuts to navigate around the page. JAWS (arguably the most common of screen readers) has several very useful shortcut key combinations. One in particular pulls up a list of all of the hyperlinks on any given page. This way the user doesn't need to wait for the reader to get to the section of the page they're interested in before finding out what kind of links the page contains. They can just use the shortcut and get a list of links all at once on demand.
It's when using the list of links shortcut that your "Read More" links are completely useless. When viewing a huge list of all the links on the page, the user is simply read the text inside the tags. There is no context. The user has no idea what preceeds or follows the "Read More" text. All they know is there's a link for them to "read more" about something. This gets especially confusing when there is more than one link like this on the page. The user also does not generally listen to the URL, as that's pretty much worthless given all the insane query strings and the computerized voice struggles with reading URLs.
Does that help answer your question?
As a screen reader user and an occasional web designer (not to mention a web accessibility consultant), sometimes ambiguous links are unavoidable. While it's not always convenient for a screen reader user to figure out the context of a particular ambiguous link, it's not that much of a burden to figure out one or two. The problems come when pages are loaded with them.
When making this decision, you really need to consider if the extra wording in the link is too high a price to pay for the convenience to a screen reader user. Usually, with a little thought, you can come up with a link text that is better for everyone. However, just keep in mind that if you do have to use ambiguous link text, you won't "break" accessibility, just make it slightly less convenient for some. On the spectrum of "must haves" to "nice to haves", this is well within the latter half, unless ambiguous links become the rule, rather than the exception.
This blog entry discusses the drawbacks of 'click here' links. Another drawback of 'click here' links is they do not help identify keywords to that might be associated with their target... think SEO.
What work, if any, has been done to automatically determine the most important data within an html document? As an example, think of your standard news/blog/magazine-style website, containing navigation (with submenu's possibly), ads, comments, and the prize - our article/blog/news-body.
How would you determine what information on a news/blog/magazine is the primary data in an automated fashion?
Note: Ideally, the method would work with well-formed markup, and terrible markup. Whether somebody uses paragraph tags to make paragraphs, or a series of breaks.
Readability does a decent job of exactly this.
It's open source and posted on Google Code.
UPDATE: I see (via HN) that someone has used Readability to mangle RSS feeds into a more useful format, automagically.
think of your standard news/blog/magazine-style website, containing navigation (with submenu's possibly), ads, comments, and the prize - our article/blog/news-body.
How would you determine what information on a news/blog/magazine is the primary data in an automated fashion?
I would probably try something like this:
open URL
read in all links to same website from that page
follow all links and build a DOM tree for each URL (HTML file)
this should help you come up with redundant contents (included templates and such)
compare DOM trees for all documents on same site (tree walking)
strip all redundant nodes (i.e. repeated, navigational markup, ads and such things)
try to identify similar nodes and strip if possible
find largest unique text blocks that are not to be found in other DOMs on that website (i.e. unique content)
add as candidate for further processing
This approach of doing it seems pretty promising because it would be fairly simple to do, but still have good potential to be adaptive, even to complex Web 2.0 pages that make excessive use of templates, because it would identify similiar HTML nodes in between all pages on the same website.
This could probably be further improved by simpling using a scoring system to keep track of DOM nodes that were previously identified to contain unique contents, so that these nodes are prioritized for other pages.
Sometimes there's a CSS Media section defined as 'Print.' It's intended use is for 'Click here to print this page' links. Usually people use it to strip a lot of the fluff and leave only the meat of the information.
http://www.w3.org/TR/CSS2/media.html
I would try to read this style, and then scrape whatever is left visible.
You can use support vector machines to do text classification. One idea is to break pages into different sections (say consider each structural element like a div is a document) and gather some properties of it and convert it to a vector. (As other people suggested this could be number of words, number of links, number of images more the better.)
First start with a large set of documents (100-1000) that you already choose which part is the main part. Then use this set to train your SVM.
And for each new document you just need to convert it to vector and pass it to SVM.
This vector model actually quite useful in text classification, and you do not need to use an SVM necessarily. You can use a simpler Bayesian model as well.
And if you are interested, you can find more details in Introduction to Information Retrieval. (Freely available online)
I think the most straightforward way would be to look for the largest block of text without markup. Then, once it's found, figure out the bounds of it and extract it. You'd probably want to exclude certain tags from "not markup" like links and images, depending on what you're targeting. If this will have an interface, maybe include a checkbox list of tags to exclude from the search.
You might also look for the lowest level in the DOM tree and figure out which of those elements is the largest, but that wouldn't work well on poorly written pages, as the dom tree is often broken on such pages. If you end up using this, I'd come up with some way to see if the browser has entered quirks mode before trying it.
You might also try using several of these checks, then coming up with a metric for deciding which is best. For example, still try to use my second option above, but give it's result a lower "rating" if the browser would enter quirks mode normally. Going with this would obviously impact performance.
I think a very effective algorithm for this might be, "Which DIV has the most text in it that contains few links?"
Seldom do ads have more than two or three sentences of text. Look at the right side of this page, for example.
The content area is almost always the area with the greatest width on the page.
I would probably start with Title and anything else in a Head tag, then filter down through heading tags in order (ie h1, h2, h3, etc.)... beyond that, I guess I would go in order, from top to bottom. Depending on how it's styled, it may be a safe bet to assume a page title would have an ID or a unique class.
I would look for sentences with punctuation. Menus, headers, footers etc. usually contains seperate words, but not sentences ending containing commas and ending in period or equivalent punctuation.
You could look for the first and last element containing sentences with punctuation, and take everything in between. Headers are a special case since they usually dont have punctuation either, but you can typically recognize them as Hn elements immediately before sentences.
While this is obviously not the answer, I would assume that the important content is located near the center of the styled page and usually consists of several blocks interrupted by headlines and such. The structure itself may be a give-away in the markup, too.
A diff between articles / posts / threads would be a good filter to find out what content distinguishes a particular page (obviously this would have to be augmented to filter out random crap like ads, "quote of the day"s or banners). The structure of the content may be very similar for multiple pages, so don't rely on structural differences too much.
Instapaper does a good job with this. You might want to check Marco Arment's blog for hints about how he did it.
Today most of the news/blogs websites are using a blogging platform.
So i would create a set of rules by which i would search for content.
By example two of the most popular blogging platforms are wordpress and Google Blogspot.
Wordpress posts are marked by:
<div class="entry">
...
</div>
Blogspot posts are marked by:
<div class="post-body">
...
</div>
If the search by css classes fails you could turn to the other solutions, identifying the biggest chunk of text and so on.
As Readability is not available anymore:
If you're only interested in the outcome, you use Readability's successor Mercury, a web service.
If you're interested in some code how this can be done and prefer JavaScript, then there is Mozilla's Readability.js, which is used for Firefox's Reader View.
If you prefer Java, you can take a look at Crux, which does also pretty good job.
Or if Kotlin is more your language, then you can take a look at Readability4J, a port of above's Readability.js.