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.
Related
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.
I'm creating a Asp.net MVC Site, and i'd like to have the message "Required" to show bellow required input fields (Not "The Field 'Name' is Required", since the message is already bellow the right field) if the user didn't fill a value. I achieved that with a custom RequiredAttribute .
Now I'm worried about someone using a screen reader. If someone is blind and is using a screen reader to read the page, it will read "Required" for this text, but since he is not able to seee the controls, it would be better if it shows "The Field "Name" is Required".
Is there a way to show a specific text in the screen, but provide another for a screen reader?
No, it's not possible, mostly because there's no way to reliably detect if a screen reader is being used. You might, and I stress might be able to inspect the User-Agent string, but that assumes that every screen reader would use a custom UA string that identifies itself as such, and that you account for all of the possible variations of those. In short, that would lead to very brittle design, if it worked at all.
I think you're looking at the issue wrong, though. Accessibility is not just about obvious disabilities such as blindness. There's people who just have poor vision, in general, but wouldn't necessarily be using a screen reader, people with learning or other cognitive disabilities, etc. The goal should always be obvious design. Does it hurt to show the entire text "The field 'Foo' is required." or would it otherwise cause any problems for non-impaired users? The answer is: no. It may be overly-verbose, but it's not problematic to show the full text. On the other hand, would hiding part of the text put additional stress on impaired users? The answer is: it might. Therefore, it's better to show the full text always.
I'm writing a blog post about the kbd element, and as part of that I'm trying to see if it actually helps in terms of accessibility, e.g. do any screen readers reckognise the kbd element or do anything with it?
I've tried googling around for an answer but turned up nothing (possibly attributed to how few people actually use this element?)
There does not seem to be any evidence of any particular handling of the kbd element in browsers, assistive software, or otherwise, except for the default rendering (which uses the browser’s default monospace).
It is difficult to image what any software could do with it, since it simply indicates that some text is presented as user input – it just represents it, without actually involving any user interaction. And the content can be just about anything. User input is often a command or a filename or other “computerish” expression, but it could equally well be in a natural language or a meaningless string (say, a password).
It would make sense if screen readers read the content marked up with kbd in a different tone/voice/speed/etc. (resp. announce it).
Otherwise it would not be (always/perfectly) clear what should be entered and what not.
Example where it would not be clear what exactly to type in:
<p><kbd>Say hi</kbd> to get an introduction.</p>
<!-- vs. -->
<p>Say <kbd>hi</kbd> to get an introduction.</p>
Example where it would not be clear that anything should be typed in at all:
<p>
<kbd>kill</kbd> to kill yourself, <kbd>kill <var>name</var></kbd> to kill the player named <var>name</var>
</p>
Example where it would not be clear if/which punctuation has to be entered and if keys have to be hold (+):
<p>To enable god mode, press <kbd>a+v!c</kbd>.</p>
<!-- vs. -->
<p>To enable god mode, press <kbd>a+v!c.</kbd></p>
<!-- vs. -->
<p>To enable god mode, press <kbd>a</kbd>+<kbd>v!c</kbd>.</p>
If any screen readers ship with kbd support enabled by default is another question, that probably can't be answered for sure, because there are many screen readers that are available only for one language resp. in one country (let alone all the different versions).
But I guess most advanced screen readers can be configured to "do anything" with kbd. I know that many screen reader users share snippets/configs on mailing lists to improve their experiences. I wouldn't be surprised if some also added some support for kbd.
Besides from accessibility for screen reader users, kbd can help other users, too, of course. I've often looked at the source to figure out what exactly should be entered when kbd didn't get any special styling.
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.
I'm a web developer, and I want to make the web sites I develop more accessible to those using screen readers. What limitations do screen readers have that I should be most aware of, and what can I do to avoid hitting these limitations.
This question was sparked by reading another question about non-image based captchas. In there, a commenter said that honey pot form fields (form fields hidden with CSS that only a bot would fill in), are a bad idea, because screen readers would still pick them up.
Are screen readers really so primitive that they would read text that isn't even displayed on the screen? Ideally, couldn't you make a screen reader that waited until the page was finished loading, applied all css, and even ran Javascript onload functions before it figured out what was actually displayed, and then read that off to the user? You could probably even identify parts of the page that are menus or table of contents, and give some sort of easy way for those parts to be read exclusively or skipped over. I would think that the programming community could come up with a better solution to this problem.
Are screen readers really so primitive that they would read text that isn't even displayed on the screen?
What you have to remember is that any HTML parser doesn't read the screen - it reads the source markup. Whta you see on the screen is the browser's attempt to apply CSS to the source code. It's irrelevant.
You could probably even identify parts of the page that are menus or table of contents, and give some sort of easy way for those parts to be read exclusively or skipped over.
You could, if there were a standard for such a thing.
I'm not very hot on the limitations of screen readers, however I've read a lot about them not being ideal. The best thing I can reccommend is to put your source in order - how you'd read it.
There are a set of CSS properties you should also look at for screen readers.
Recommended listening: Hanselminutes
It's an interview with a blind programmer.
How many forms just have a * or bold to indicate to a sight user that a field is required for correct submission? What's the screen reader doing? Saying "star"?
Below is an example of code that is helpful by articulating verbally but not visually.
(note - in the example below the word "required." is spoken but not seen on screen)
In the template:
<label for="Requestor" accesskey="9"><span class="required"> Requestor * </span><span class="hidden">required.</span></label>
In the CSS:
#hidden {
position:absolute;
left:0px;
top:-500px;
width:1px;
height:1px;
overflow:hidden;
}
or
.hidden {
position:absolute;
left:0px;
top:-500px;
width:1px;
height:1px;
overflow:hidden;
}
There can be a whole parallel view behind the "seen" in every X/HTML page.
#robertmyers
CSS contains the aural media type specifically to control the "rendering" of things when screen readers are doing their work. So, for you example, you would only set it as visible for the aural media type.
#Ross
I'm quite aware that the screen reader doesn't actually read the screen, but you would think that to work well, it would have to build a model of what a person with sight would see, otherwise, it seems like it would do a really poor job of getting across to the user what's actually on the page. Also , putting things in the order you would read them doesn't really work, as a sighted person would scan the page quickly and read the section they want to read. Do you put the contents first so that the user has to listen to them every time, or do you put them at the end so that they can get to the content first? Also, putting content in order would mean some tricky CSS to get things positioned where you wanted them to be for sighted users.
It seems to me that most web pages contain very similar construction, and that it should be possible to, in many cases, pick out where the repeated headers and side columns are. When viewing many subsequent pages on the same site with the same formatting, it should be easy to figure out which sections are navigation, and which are content. Doing this, the screen reader could completely skip the navigation sections, and move right onto the content, as most sighted users would do.
I realize there are limitations, and that doing these types of things wouldn't be easy. However, I feel like as far as screen readers go, we only did the bare minimum and left it at that.
Have a look at ARIA, it's a standard for developing accessible rich-web-client applications.
#Kibbee,
What you are describing as "primitive", is in fact a feature of screen readers that can be, and is, used to make sites more accessible. For example, if you have a tabbed interface, implemented with an unordered list and list items, then the sighted user would normally see the selected tab highlighted with a background color that is different (or some other visual treatment). Blind users cannot see this. So adding some additional text into the page and hiding it off screen is the technique used to communicate to the blind user what tab is active.
In the accessibility lingo, this information is known as role, name, value and state.
There are many other scenarios where this technique can be used to add information that is useful for a blind user.
More recently, WAI-ARIA has been added to allow this state, role, name and value information, so you can now implement a limited number of widgets (like tabs) using HTML attributes. However, the more general "off screen" technique is still useful.