How do you get a screen reader to properly read something like:
<nav>
Home
FAQ
Contact
</nav>
(I.e. read it as "F A Q" instead of "faq").
It doesn't make sense to use <abbr> here since "FAQ" is well-known.
I've tried:
speak-as: spell-out; CSS property, but apparently it's not well supported by screen readers and seemingly has about 3.5% global browser support anyway
FAQ which works on my screen reader (Orca). However, I'm worried some will read out the bullet points, and I believe aria-label is meant for interactive elements so I'm not sure it's a good solution for things like <h1>FAQs</h1>. In fact I think many will ignore the label entirely for an h1
The <h1>FAQs</h1> issue raises further concerns about reading that out properly (i.e. the addition of the "s").
Is there a better solution to this?
IF you want to do something, the only really good answer is <abbr>.
As you have said, though, FAQ is a well known acronym, and as such, you don't need to expand it explicitly.
If you don't want to use <abbr>, or as in the present case, judge that it's unneeded because the abbreviation is so common, in fact, don't do anything else.
You may use aria-label on a link, or visually hidden / off screen text, but in fact it's bad ideas, because you are probably going to create more problems than to solve.
<abbr> is good because you can decide, in screen reader options, whether abbreviations have to be expanded or not.
For the rest, most screen readers come with a pronunciation dictionary, normally customizable by the user. If they don't understand the word "FAQ" pronounced as such, they can add it in their dictionary to make it pronounced as "Frequently asked questions" or "F, A, Q", depending on their own preferences.
If you interfere in there and force the pronunciation to something the user doesn't know, they will maybe not understand what it is; and hence you have made experience worse.
Related
With NVDA (screenreader on Windows),
<p>The 36" product had this option.</p>
reads as "the 36 quote product is"
With VoiceOver (screenreader on MacOS), it reads as "the 36 inches product is"
To meet basic WCAG 2.1 Level A requirements, should I be using an aria-label or similar to get NVDA to read "inches" properly, or is this an NVDA issue?
Looking at the WCAG docs I had trouble finding specifics about units of measurement.
When you mix in CMS, it might get messy. Ignoring CMS for the moment, when a screen reader encounters punctuation, there are a variety of things that could happen.
The first is that the user might have certain verbosity levels set. Some verbosity levels announce all punctuation, including commmas in sentences and periods at the end of sentences. That's not usually a desired behavior when navigating a normal website but can sometimes come in handy such as when you're writing javascript code and need to hear all the punctuation because it's part of the language.
Another verbosity level is some punctuation. Commas, periods, question marks, exclamation points, etc are usually not announced but others such as quote marks might be. As far as which characters will be announced, it varies from screen reader to screen reader. Some screen readers will let you choose exactly which characters should be announced.
There's also another feature on screen readers that let you change what is announced for a particular character. It's essentially a dictionary of pronunciations. So I could have " announced as "quote" or "inches".
Also note that you can have different quote symbols such as. Technically, I think the first is called a "double prime" and the second is a real quote mark (which might look different if you have an "open quote" character and a "close quote" character, where the angle of the character looks different) and the last is a "straight quote".
Because of the variety of screen reader settings and actual punctuation characters, if you want something announced a certain way, it's best to be clear and specify it yourself.
I would not recommend using aria-label unless you are specifying the aria-label on an interactive element. If you have plain text, it's better to use an "sr-only" type class that provides text for a screen reader to announce but the text isn't visibly displayed on the screen. See What is sr-only in Bootstrap 3? for more info on "sr-only".
So you could have something like:
the 36<span aria-hidden="true">"</span><span class="sr-only">inch</span> product
In addition to the "sr-only" on "inch", I also added aria-hidden on the quote/inch symbol so that the screen reader will ignore it.
The end result is that the sighted user will see "the 36" product" and the screen reader user will hear "the 36 inch product".
Note also that a Braille user will read "the 36 inch product". They won't read the quote symbol because it's hidden from assistive technology. They'll read the actual word "inch".
Don't do anything to fix pronounciation issues like this. You have greater chances to create other problems than to fix them.
In fact, it isn't related to NVDA or VoiceOver, but rather to the actual voice used.
Each voice make make a different interpretation of the text, and none is always correct in all situations.
Remember that
Screen readers and speech synthesis don't make advanced language processing, if ever they do some at all
As a consequence, they can't guess correctly what you really mean, semantically speaking, all the time
You have almost no control on how to change the interpretation or help it figure it out. There are pronounciation dictionaries under user's control, but it doesn't solve everything.
I'm a screen reader user myself, and in fact, for the best and the worst, we are quite used to that kind of pronounciation or interpretation issues.
This is generally not a big problem, because even if it isn't read exactly as you think it should, we are smart enough to understand what it means anyway. Sometimes we even make fun of it.
You may use a more specialized unicode character instead of the normal double quote, for example U+2033, but it isn't ideal either:
Many screen readers and/or voices don't support such characters, leading to garbage or nothing at all pronounced
As far as I know, this U+2033 can have several interpretations, too: inch, seconds, or double prime
You may use the visually hidden / off screen text + aria-hidden technique, like this:
Product X is 36<span class="sr_only"> inch</span><span aria-hidden="true">"</span> long.
But it's probably quite complicated for what it's worth in this particular case.
Think also about the fact that the symbol " is probably understood almost everywhere when it means "inch", while the word "inch" itself has to be translated, if your site is multilingual.
It's often forgotten, but labels, alternative texts and hidden texts have to be translated as all other texts.
Note that this interpretation problem isn't limited to characters like " that can be taken as "quote" or "inch". For example, some voices will systematically say "centimeters" for "cm", while it may be incorrect in some contexts. Other example, "min" can be interpreted and spoken as "minimum" or "minutes".
The world of abbreviations and symbols is very complicated, but keep in mind as a tl,dr that despite a lot of small imperfections of that kind, we are smart enough to figure it out anyway. Don't try to find workarounds that might help some people, but make the experience worse for many others.
Most likely the difference comes from how the different screen readers interpret the same input. While the quote seems "obvious" to VoiceOver that you meant "inches", it wasn't that evident. You can't do pretty much anything about that, other than providing hints for the readers so that they all don't need to interpret anything.
A quick solution could be
<p>The <span aria-label="36 inches">36"</span> product had this option. Bla bla bla.</p>
Here you insert hints for the reader where something "confusing" appears.
Another, more extreme, way of doing the same would be to provide an entirely different content for the screen reader, tailored knowing their limitations besides the normal one:
<p aria-hidden="true">The 36" product had this option. Bla bla bla.</p>
<p class="screen-reader-only">The 36 inches product had this option. Bla bla bla.</p>
The first paragraph is visual-only, note the aria-hidden attribute that instructs readers to ignore the whole thing. The next one is crafted from the first replacing problematic characters with the proper text. The class is defined as follows:
.screen-reader-only {
position: absolute;
height: 1px;
width: 1px;
clip: rect(1px 1px 1px 1px); // IE 6 and 7
clip: rect(1px,1px,1px,1px);
clip-path: polygon(0px 0px, 0px 0px, 0px 0px);
-webkit-clip-path: polygon(0px 0px, 0px 0px, 0px 0px);
overflow: hidden !important;
}
Which basically hiddens away from view this chunk of text, while still allowing screen readers to pick it up and reading it.
Source and full explanation of this last trick: https://accessible360.com/accessible360-blog/use-aria-label-screen-reader-text/
Also have a read here for more details on handling special symbols for screen readers: https://www.deque.com/blog/dont-screen-readers-read-whats-screen-part-1-punctuation-typographic-symbols/
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.
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.
I have found that setting a very basic style reset or style sheet initialization as I prefer to think of it has caused an unexpected result as certain browser defaults were effected. This (me being stupid) led me on a merry dance until I realised that I had turned off the default by employing the reset.
I am now carefully picking through all the pages identifying any other adverse effects.
I suppose that it very much depends on personal preference whether you use a reset or not and I may of course be over thinking this which is the curse I carry. Nevertheless I would like an opinion on whether this is good practice or a good way of over complicating everything.
If it is good practice is there a particular time when it is appropriate to apply a reset.
Eric Meyer's article reset reasoning made perfect sense to me hence employing a very basic reset. I did not employ the full Eric Meyer reset which of course may well have been my downfall. I am not intending to revisit that at this stage.
However I would like to know going fwd what considered opinion is and whether I should be attempting to apply this in future.
Regards
This absolutely depends on the way you write your webpages and the size of your project. Most pages would be 'meh, okay' without reset, but not perfect or consistent on all browsers.
It's trivial why one might use CSS reset -- the more interesting question why not use it?
If you rely on browser-defined default styles (like, for instance, the way h1, h2, h3, h4, h5, h6 get rendered or how ul bullet-lists behave by default, or default margins/paddings, etc...), then resetting your CSS will probably have you do some extra work. In other words, doing reset will bring back all HTML elements back to almost 'nothing' -- just a bunch of semantic grouping tags...
Which is good.
It's what HTML is supposed to be like, not for styling; but for logical and semantic grouping. Styling your elements from scratch will give you much more control, and will save you some browser-specific tweaks and pain.
Plus, jsFiddle does it, so it must be some good!
as certain browser defaults were effected.
Any other defaults that weren't effected would be a bug, since that's the whole point of a reset css.
The one bad point about a reset stylesheet (assuming it has no bugs in itself), is that you have to think about the style of every element used.
The good point about a reset stylesheet, is that only you have to think about every element used. Not using one is a bit like working with a colleague you don't communicate well - it'll save time when they happen to do things that go well with your work, but whether you are duplicating work or letting some case fall between the gaps and get ignored won't be obvious.
In practice, it depends upon which of the two philosophies suits a project best:
You're happy for a lot of styles to depend upon the browser default and (the plus of this approach) user settings. You only add what CSS is necessary, and let such things as default sizes and fonts depend on the browser.
You strive to have a very precise say on every element.
There are pros and cons to both these approaches, and the pros of the second approach has increased lately, as the mechanism used by browsers for re-sizing text for legibility has changed meaning that more of them resize the whole page rather than just the text (this was a big problem with taking the second approach before - you would either have some settings break your design, or have your design break settings some users depended upon to be able to read it at all).
With the first approach, using a reset sheet smashes through the very philosophy you are taking, ruining everything for you.
With the second approach, using a reset sheet is a good first step to getting going. Any time you find that the reset sheet caused a problem, what you really found was that there was something you should have been doing, that you didn't do, and it highlighted that problem for you. If you accomplish the second approach without a reset sheet, then you've effectively arrived at the same result you would have with it, at least as far as those elements used go.
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).