I am building a website and I am attempting to make it as accessible as I can by the use of ARIA tags, role tags etc.
A navigation menu item is "Changing Lives". Where this is being read out by screen readers as "Changing Lives" (as in "Gives" and not "Knives").
Another navigation menu item is "About Us" but it is being read out by screen readers as "About U.S.".
I'm looking for assistance in how to force pronounciations for screen readers.
Don't worry about it, there are many words that screen readers do this on.
The only way you can influence pronunciation (while adhering to best practices) is to set the HTML lang attribute (language) correctly.
With regards to your About Us issue, capitalisation plays a big part in pronunciation. If you have used upper case (either in CSS or in HTML) it may exhibit this behaviour.
Above all do not resort to hacks such as double letters to fix this.....fixing it in one screen reader will break it in 3 others....just follow best practices.
You have the same problem as the user in the following question, and the same answer should apply:
VoiceOver pronunciation issue: "Live" "ADD"
you can ignore it,
you can use different words.
Related
I am hoping someone could enlighten me on exactly what is the fix to pseudo classes and content negatively impacting screen readers.
For example, if I have this piece of code in my SASS file:
[bag-total]:before{
content: attr(bag-total);
}
My intent here is for the screen reader to read the value of the attribute or the total amount in the users' cart that he is about to purchase.
The problem right now is the screen reader is not reading the number of items in total inside the shopping cart.
The :before and :after pseudo elements are used in the "accessible name" computation as defined here - https://www.w3.org/TR/accname-1.1/#step2. Specifically, step 2.F.ii
The process looks complex but if you think of simple cases, such as a button, the accessible name is essentially the text label of the button. However, a button that displays "read more" might make sense for a sighted user because they can see the context around the button, but for a visually impaired user that is using screen reading software, "read more" might not be sufficient. It's possible to add more context to the button label using ARIA attributes. The additional context is not visually displayed but is used in the "accessible name" computation, which is why that process looks complex.
The same is true if your button just displays an icon. There is no visible text but you need some way to describe the button's icon so that the "accessible name" will make sense.
If you use :before and :after pseudo elements to add more context to your element, that additional context needs to be included in the "accessible name" computation.
Now, all that being said, I'm not sure what kind of "fix" you're looking for. You didn't really state what the problem is you're trying to fix.
It looks like the CSS and user-agent specifications support what you're trying to do here, but inconsistent browser support may ultimately prevent it from working well.
I tested your method using NVDA on Windows with several browsers, and Internet Explorer was the only one that had difficulty. IE still has a fairly sizeable user-base, so it's probably worth supporting if you can.
Unfortunately, I can't see a good solution to your problem unless you want to use JavaScript or a server-side scripting language. Both of these methods add the content to the DOM, whereby CSS doesn't.
This page has some good information on the accessibility of pseudo-elements that seemed to confirm what I was seeing in my own testing.
https://tink.uk/accessibility-support-for-css-generated-content/
Could some one please help with differences between those two screen readers? As I was faced with one issue while testing the accessibility using them. Of course, I fixed the issue with screen reader only (Bootstrap's class to span element to read the sort order).
There are a lot of ways to answer this question. It partly depends on version and with which web browser the screen reader is paired. In short, that matrix can make it pretty complex to identify all the differences.
For example, CSS is handled differently by different screen readers: http://webaim.org/blog/screen-readers-and-css/
Or take a look at the HTML / ARIA / WCAG tracking PowerMapper does: https://www.powermapper.com/tests/screen-readers/
Perhaps most relevant to most users is that NVDA is free and JAWS is not.
If there is a specific issue you are trying to address, then you should just ask that question instead.
In foundation please explain it with any good example. I couldn't understand the difference from zurb-foundation documentation.
1) hidden-for-* vs hide-for-*.
2) visible-for-* vs show-for-*.
It gave a pretty good explanation, I think, with this quote:
Adding display: none to an element will prevent screen readers from
reading it. However, there are techniques to hide content while still
making it readable by screen readers.
If I wanted to show/hide a piece of content specifically for screen readers, I would use hide-for-* and show-for-*.
hidden-for-* and visible-for-* Are for regular uses. Hiding and showing content based on screen size for all users. For example, changing the size of a header.
hide-for-* and show-for-* Are for accessibility uses. Hiding and showing content based on screen-size specifically for screen-readers. For example, changing the size of clickable buttons or showing some meta information because it would be difficult to otherwise access that information from a screen-reader.
I hear of advice of making the .hidden class not as a
.hidden { display: none }
but make it width and height of 1, and using clipping, etc, to make the element as if it still exist on screen but the content is just not visible.
But isn't it true that when we use JavaScript to hide something, the purpose of that element is done, and we want it to not show on the screen and not visible to the screen reader either?
Case 1: For example, if it is an input box, and inside the box there is a grey line of text "Enter keyword". When the user actually clicks on, or keydown, (or using the input event), now we have a JavaScript handler to hide the "Enter keyword" text, because it is just a grey prompt inside the input box. In this case, shouldn't the text be completely hidden, using in fact a display: none, so that even screen reader can't read it? (the user have learned enough to start typing, so the prompt shouldn't really still be there to be read by screen reader, right?)
Case 2: If it is a pop up bubble, for error message, or there is a link "enter your email for our subscription", and it will pop up a bubble, then when the bubble is closed, shouldn't the bubble be really closed totally using display: none? The screen reader shouldn't really still be able to read those content out for a bubble that is done and closed.
Case 3: The only case I can think of is a small fraction that the "hidden" should be available to a screen reader is: it is for a bubble for extra information, such as for the product rating (how many stars out of 5), or extra help info that can pop up when the mouse hover over some "?" icon or link. But even in this case, won't screen readers actually read out "link to more info" or "link to show rating", that is in the alt or title of the tag, and not read the pop up info until the user pops it open?
So my question is: shouldn't there be really two types of hidden. One is display: none type that screen reader shouldn't see (make it the .hidden class), and the other is width: 1px; height; 1px that the screen reader can see (or will read out) (make this the .a11y-hidden class), and whether type 2 might be far less often than type 1?
Mostly, that's it.
EDIT 2014: I switched to the clipping method from TJK at Yahoo! (because of hidden span into a link where only an <i>con is visible).
I prefer position: relative; left: -5000px over clipping 1x1px, I know that Yahoo! team only use the latter but the aim is the same.
Also I'll call it .visually-hidden (from Twenty Sth theme in WordPress and other CMS and frameworks). .a11y-hidden would mean the contrary: it's only visible (perceivable) by screen readers and in plain HTML.
Tabs content, error messages that didn't occur yet (your Case 2) shouldn't be perceived by anybody. A screen reader user will have to click on a tab to show its content as everybody else.
Note: display: none AND visibility: hidden elements will be ignored by screen readers. And also some of them (VoiceOver on OS X in particular) will ignore an element with height: 0, etc
Relevant article : Invisible Content Just for Screen Reader Users from WebAIM
Case 1: the important part being read out is the label associated with for/id to the form field.
If you use a keyboard to navigate from field to field, this text will have disappeared when you'll have focused it and it won't be visible to users that zoom at x00%. HTML5 introduced the placeholder attribute that has the same role as this prompt (this is NOT a replacement for label, this is a hint but few people read one of the HTML5 doc alas) and can still be passed to screen readers even if it's visually hidden.
Case 3: this information should be coded in HTML in an accessible manner and so you wouldn't need to visually hide information out of the viewport or in a pixel.
alt text is the preferred manner (or even better a visual with some real text by its side, while avoiding too much clutter. I've no training in ergonomics and this will often annoy webdesigners that want to remove everything from a page ;) ).
title attribute should only be used on links and you're never certain a screen reader will choose to read them. It's a personal matter and setting on a per site basis. They can be so annoyed by some sites that they'll disable these titles everywhere... Though, it's still one of the best techniques to add information if for some reason you can't do it otherwise.
How do I use this .visually-hidden class?
quick access links (to content, navigation and search input) when they don't appear in the mockup. When focused, they'll be brought to screen as in http://www.nanomatrix.fr/ (press Ctrl-L or Cmd-L, tab half a dozen times on Windows and enable tabbing through links in Safari and/or OS X. See on upper left the 3 links)
on labels when for some (bad) reason, they're not in the mockup I receive. Better have a fix (it's a good one) than doing nothing to improve accessibility when it wasn't thought of beforehand...
on captions of tables, because most of the times showing them is a no from client, external webdesigner, etc
on a span with information next to a font icon when it's coded in a performance manner but not very accessible. There are many ways of using a font icon, I'm only speaking of a few use cases
Theres a lot going on here that needs to be addressed.
Firstly, and ideally, the grey text in the input box should be handled by the 'placeholder' attribute. The browser will give the user a consistent and expected behaviour, and its also easier for you to code!
Secondly, for accessibility ideally all inputs should always have labels. This is so that the input is described correctly to screen readers. You can hide them if the design doesn't call for them (some websites only use placeholder text, but that doesn't mean they shouldn't) be there) - which brings me to my third point - hiding content on screen but not from screen readers:
{display: none} will hide information on the screen AND from screen readers. It's basically a way of making something disappear - for everyone. This is where the .visuallyhidden class (or similar) comes in - its a way of adding context (extra information) to the DOM that will be picked up by screen readers but not read by sighted users and it's a technique used very often to make pages more understandable to AT users without breaking a layout or design of a page.
Its a good idea to use a tried and trusted class, such as the one inside the HTML5 boilerplate, as getting it wrong could penalise you on Google (for trying to blackhat content) or create problems with some screen readers on some devices (e.g. iOS) - position:left and text-indent is not a good solution for a number of reasons, so stick to the 1px and clipping technique.
How Screen reader behave with <hr> <b> <i> <big> <small> <br /> ?
I am a jaws user and tags such as
<b> <big>
etc are not read in any special way to distinguish them from the rest of the page by default. If you want to point out a specific region of a page follow the stackoverflow example and use headings. I can quickly go from question to question since they each have there own heading, and when viewing a question can quickly jump from the question to the answers. ANother good example of heading usage is the way that google reader gives each headline it's own heading.
Really depends on the screen reader. Typically they will ignore tags they're not expecting, read some tags and change the tone of text surrounded by others.
The best way to find out is to run it through the one you're intending to support. For example, JAWS (a widely used screenreader) has a 40 minute demo that you could use. Bear in mind that this will be different for other screenreaders.
The rule of thumb is to make sure your markup is as semantic as possible and also conforms to what users of screenreaders are expecting (trying to be clever or overly helpful can actually be counterproductive if it is different from every other site your visitors have been to).