Ashley Sheridan​.co.uk

Tags:

Screen readers are an essential tool for people who are unable to see, or who struggle to read. Sometimes though, a screen reader needs some extra help, as it can struggle with the right pronunciation of a word, name, or abbreviation. There are things we can do to help nudge screen readers in the right direction in a way that doesn't break the user experience for other people.

Contents

• The Problems
  • Contextual Pronunciation
  • Spoken Abbreviations
  • Proper Nouns
  • Wrong Symbol Use
• Conclusion

The Problems

There are a few types of problems that screen readers can encounter when trying to speak out your content:

• Words can be spoken differently depending on the context. The English language is full of homographs where context is essential to correctly pronouncing the word
• Abbreviations may be spoken differently from the way they're spelled. For example, the acronym SQL is often spoken as "Sequel"
• Proper nouns, such as company names or products, may have particular pronunciations, especially if they are compound words
• Wrong characters used where a correct one exists, such as using a letter 'x' in place of a multiplication symbol (×) when referring to multiplication

Contextual Pronunciation

Take the word "read". This is a classically confusing homograph in English, and depending on the context, the word has very different meaning and pronunciation:

"Could you read the memo"

"The memo was read"

Most screen readers will correctly read these sentences out correctly, but what about when the word is without any context whatsoever?

For example, in an application with messages, a button might be labelled "Read". A screen reader would have trouble understanding whether this is a filter to show all the read messages (past tense), or if it's an action to begin reading the message, so the pronunciation could be wrong.

The solution to this problem would be to try to use alternative wording that isn't as ambiguous. What you must not do is try to add ARIA labels to the button with a phonetic spelling. This would fix the problem for people using speech readers, but create a whole new set of problems for Braille users, as they will be presented with the content of the ARIA label, which will make no sense to them whatsoever. A Braille device will present the phonetic spelling as-is.

So in order to express either of the two status and action messages, you could re-word your content to become "messages you have read" or "read this message".

Spoken Abbreviations

I mentioned a previous example of SQL, which is often pronounced differently from its spelling. There is a perfectly suited HTML tag available for this: With this, you can supply the full meaning of any abbreviation the first time you use it, and mark any future occurance without:

A screen reader will still speak out the individual letters of the acronym, but that's generally accepted for this type of abbreviation.

But what about abbreviations which are not acronyms? Consider NodeBB. Spoken out by a screen reader, this sounds more like "no-deb".

So what can you do to help screen readers without breaking the experience of everyone else? The solution is to use a zero-width space character (​).

There is one downside of this though. Text that is visually justified may insert a space in the place of this of this character as if a regular space had been used. People using Braille devices on the web will have the correct version presented to them on their display, visually it will appear the same as before, but now speech readers will also present it in a way that is more understandable to people relying on them.

Proper Nouns

The one area that is most difficult for speech readers is names that aren't existing words. Consider the name MySQL. This may be pronounced in normal conversation as "my sequel", or "my s-q-l". However, some screen readers, when encountering the MySQL name, will pronounce it like "mis-kel". Obviously, that is confusing for the the people relying on it being read out to them.

Again, some zero-width space magic to the rescue:

Screen readers will recognise the space and read it out as if it were two separate words:

Again, this may cause some visual issues when using justified text; test it out against your own designs to see if you will be affected.

Wrong Symbol Use

Many years ago I was building a website for Energizer Europe. One of the products there needed to reference how much longer lasting it was than a rival brand, so the content looked like this:

That's right, it was using a capital letter 'X'. I argued for the use of the × symbol, as it was correct and would be read out as expected by screen readers. Unfortunately, I didn't hold to my position as well as I should have and I didn't know enough about ARIA, so the website went live with a known problem for screen readers. The argument for keeping the letter instead of the correct symbol was one of visual aesthetics, as the × symbol didn't exist in the chosen font, so it would have varied in appearance from system to system.

I blame myself, because the solution would have been fairly simple:

Or even to use unicode-range in the font declaration in the CSS to force a specific font to be used for specific characters.

I would always advise installing and becoming familiar with a good character map program on your computer. KCharSelect is available on both Linux and Windows, and offers search features I've not found in any other similar tool.

Conclusion

It's worth testing out your content with a screen reader. There are plenty available, free and paid, for every available operating system. The JAWS screen reader for Windows is very powerful, and they offer a 40-minute trial and then a variety of paid options once the trial expires. Linux has Orca and Jovie, which are capable but have less features, both of which are installed by default and can be enabled very simply from the system settings.

The important thing to remember when you encounter problems with the way your content is spoken out is that you should try to keep in mind that ARIA attributes on your HTML tags are not just for screen readers. Avoid using aria-label, for example, to describe something which already has a text alternative. If you absolutely must do this, try to ensure that it still makes sense if it were presented as pure text.