How can I make sure screenreaders always read the right thing?
As example, if I have:
<p>I want a cheeseburger w/ tomato and lettuce.</p>
the screenreader may say "I want a cheeseburger W slash tomato and lettuce.".
On a bigger scale, you might wright some text as a bunch of symbols, but a screenreader may be confused, and read the symbols, instead of what the intended meaning is.
Such as, if I head this JSON:
{
"code": "tLk5902cqC1583r",
"expiration": "03/03/2022"
}
How could I have it read off "JSON that reads a code of T capital L k 5 9 0 2 c q capital C 1 5 8 3 r, and an expiration date of March third, twenty twenty-two." instead of the possibility of reading "Opening brace, code, colon, tLk5902cqC1583r, expiration, ..."?
Going back to earlier, how can I do something in this fashion?:
<p>I want a cheeseburger <annotation readas="with">w/</annotation> tomato and lettuce.</p>
...I know, the realistic thing to do would be to design a the webpage better, use "with" instead of "w/", etc... and same for the other example.
Though, there may be cases where this isn't possible, which is when I'm thinking of using this.
I know <img/> has alt, but what do other elements have, in terms of capabilities for helping screenreaders? Can alt be used on anything to help screenreaders read it? If not, how do I do what I said I wanted to achieve? ${Etc...}?
Cheers!
Latest comments (8)
I think this is a great question, and thank you for caring about the experience of an assistive technology user. The short answer to your question is do nothing.
The reason for this is screen readers have a few features to help out with exactly this sort of thing. First are screen reader heuristics, which analyze content and announce it based on what it expects the phrase is. Second are user-defined pronunciations, for things that a user would explicitly want spoken in a certain way. Third is verbosity settings, which control the level of chatter the screen reader has.
The reason you don't want to adjust announcements is you might override a user's settings, and therefore expectations for how this content is announced. If there is confusion over the announcement, there are methods for a screen reader user to go over the content in a more granular way to figure out what is going on.
As for ARIA and the
titleattribute from previous comments, three things:titleattribute should not be applied to anabbrelement. Here's a good explainer by someone who know their stuff.role="text"isn't well supported, and also wouldn't be applicable in its use here. Here is another good post to reference.The answer to the question is less "here's how you do it" and more "you don't need to do it," and by not doing it you're actually providing a better experience for your users!
Are there still times when manually adding your own definitions can help? (E.g. in the case of the JSON example I provided. Even though that's one of many examples that could be thought of, that involve making the SR confused.)
There might be some extreme cases, but the JSON example is another case of not needing to do anything. There's enough context in the native semantics of the elements you're using to display the code example, as well as the surrounding content.
Less is more definitely feels weird at first, but it's important to remember by not over-describing you're making things better. Here's another good post on this topic.
Alright.
Though, how do if I know I'm using the right elements for screenreaders?This look really good and I will also start using this in my next projects, thank you.
In HTML, you can use the
<abbr>tag to specify abbreviations and acronyms, using thetitleattribute to specify what the abbreviation/acronym stands for:Unfortunately, screen readers won't read the title and will try to read the text as is ("w slash" instead of "with"). You can fix that by adding an aria-label with what you want the screen readers to read. This would be equivalent to the "readas" attribute that you mentioned:
With that, some screen readers read it as desired (Chromevox) but others still read "w slash" and broke the sentence in parts (VoiceOver). Adding a
role="text"to the paragraph helped with this:After that, VoiceOver and Chromevox read it the same way: "I want a cheeseburger with tomato and lettuce." But I recall some a11y experts mentioning
role="text"not having full support (would need to look into it), so I don't know how good of an idea it is to use it.It is funny because sometimes screen readers are smart enough to interpret this type of acronyms correctly, and some other times they need a little help.
Sometimes they may "need help" since they're trying to be "accurate", instead of being "correct". At least, that's why I think it happens.
But, I had a question about
<abbr>, istitlerequired for the example that includedaria-label?I know
titlealso adds a tooltip to the element, and I don't want that.titleis not required. With the tooltip, you'd be providing the same information to screen reader users and sighted users, which is important. But we could say that "w/" is a commonly known/used abbreviation and there's no real need for the title/tooltip. So it should be ok without it.