I am using change language drop-down in my web-application, I am working on accessibility of web-application, while working on accessibility I discovered that when particular option is selected from dropdown voiceover just pronounces the selected option,but inorder to make it more accessible I wanted to pronounce it as value selected. Is it possible to prefix text 'selected' in voiceover / screen reader pronunciation?
Please find the code below
<label for="lang">Choose Language:</label>
<select name="lang" id="lang">
<option>English</option>
<option>日本人</option>
<option>русский</option>
<option>中文</option>
</select>
Thanks
This is once more the famous question "How do I make the screen reader to speak X instead of Y ?"
The general answer is, if you want Y be spoken instead of X, then just write Y and not X. If it isn't appropriate to write Y, why should it be to speak Y?
Why a scren reader should speak something different than what's written?
I won't make the whole discussion here again, but except in relatively rare cases, things shoult be spoken as they are written. If it isn't the case, you may create problems for several ranges of people: partially sighted people who rely in both speech and written text won't hear and see the same; it's unclear if braillists should read X or Y depending on how far you consider braille as being as writing system per ce; etc.
As the name says, a screen reader is there to read what is written on the screen.
For all the rest, important information not really written directly on screen, like the fact that an item is selected or not, all screen readers have adopted different strategies and often they are configurable.
For example, the word "selected" might be said before or after the selected element; a different voice might be used; the pitch might be made lower or higher; A sound might replace the word "selected" altogether; etc.
The best is to not interfere in any way with how exactly that kind of information is given to the user.
By interfering, you might clarify things for one specific group of users, but confuse all others.
In the case of selection in a combo box, just use the selected attribute appropriately, or maybe aria-selected for custom components, in order to mark the selection properly.
From there, leave screen readers report selection to the user as they are used to do it. Don't do anything special.
Related
Right now I am setting the focus on the very first editable input field, during page load.
In terms of page accessibility, If the very first element is "read-only" input field then is it valid or meaningful to set the focus on the input field with cursor disabled ?
The question you should be asking is should you interfere with the user focus at all?
You may think it useful to automatically focus the first input (whether it is read-only or not) but this may not be as useful as you think.
When the page loads the user is expecting to have to use your skip link (I assume you have one, if not add it) to bypass the menu and get to the content of the page. However they may not want to as they may want to check they are on the correct page through breadcrumbs, menu position (assuming you mark the current page in some way) etc.
I am also assuming you have a <H1> on the page to reinforce that they are where they think they are on the site so they would expect to see that also.
If they are filling in a multi-page form then they will use screen reader shortcuts to look for the next form, if you have more than one on the page (search box, quick contact etc.) they would end up navigating away from your form by mistake instead of landing on it.
Now assuming that even with all of the above it is actually a better user experience to focus the first input (I am not saying it isn't, just pointing out the above considerations) should you focus the first 'read-only' input.
The answer is nearly always yes.
If a non screen reader user will see that information before they see information that requires inputting / editing then a screen reader user should also see it first.
The only exception to this would be if all of those read-only fields are a summary of everything entered so far in a multi part form.
In that case (as a rough rule, yet again use your own judgement) you should still provide that information first but make sure there is a heading / legend / field set title etc. that indicates that this is previously entered information and provide an easy way to skip to the fields that require input.
It is perfectly acceptable to have 'skip links' within the document, they don't have to just be for menus.
You do this so that they have the option to check previously entered information is correct and know it is available on the page to refer back to, but also don't have to tab past every single field if they don't want to check the information entered previously.
As with everything in accessibility, each use case is slightly different so the only real answer is 'it depends', but hopefully the above will help guide your thought process on what will work best.
This is where user testing is your best friend, only real world screen reader users who do not know your site design and layout will let you see if you made the best choice / which scenario works best.
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.
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 trying to find a way to make screen readers like NVDA of Windows Narrator stop reading an input value and read the aria-describedby only instead.
Here's the case, I have a web component that is a mask-input field. Let's say it is configured with a phone mask set to (___) ___-____ where underscore can only be numbers. Right now the screen reader would read left parens, 3 lines, right parens, space... and so on and then read what I set as the aria-describedby value which would be something like "Phone number, 1231231234" which use the unmasked value of my component.
What I'd like, would be the screen reader to only say "Phone number, 1231231234" which is my aria-describedby value and skip the rest so it keeps short and avoid saying things that can confused impaired user..
A bit of background, maybe this can change a bit the response, my component is built with Aurelia, I'm leveraging the binding system to update the value.
Is this something possible? I there a few alternative? I'm I completely off-track with what I'm trying to achieve?
Thanks!
There isn't a lot you can do to maintain accessibility with this approach. It is very important for the screen reader to read out the contents of the input field, otherwise when a user types a number it will not tell them what that number is - also if they decide to go back a character or forward a character, the value will read the label and not something they've entered. I imagine the input mask you're using is using javascript to replace a masked character with the user submitted one on keypress?
It is generally best practice to outline what the required input format is in the label or in descriptive text associated with the label. This will allow sighted users to easily match the required format and also allow visually disabled users to use their keyboard to navigate the input value with full knowledge of what the desired format is. I've thrown together a quick example of this.
<label for="textInput">Phone Number</label>
<span id="phoneDesc">Please use the following format: (xxx)xxx-xxxx</span>
<input id="textInput" type="text" aria-describedby="phoneDesc" />
It could also be helpful to look into the general usability of input masks - a lot of people tend to find them troublesome.
https://www.nngroup.com/articles/stop-password-masking/
If you're determined to use them and don't mind a different approach from your 'line' based approach, maybe give politespace a try (I have not tried this, but it could be worth evaluating for your needs)
https://github.com/filamentgroup/politespace
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.