Written by: Jonathan Avila

If you’ve ever used a GPS navigation system or app while on a road trip, you know that sometimes the software can’t parse an abbreviation or pronunciation that we take for granted. For example, St. Dunston Lane gets read as “Street Dunston Lane” or McLean is read as “McLEEN” instead of “McLANE.” These are not life or death issues in terms of vehicle navigation or accessibility, but they can be annoying.

What do you do when a screen reader is mispronouncing a word that you consider important to your organization’s message?

In general, we do not recommend screen reader specific phonetic text to make the screen reader announce the word properly. It is understandable and acceptable for a screen reader to make pronunciation “mistakes” occasionally. Oftentimes, the way a screen reader announces the word will vary, depending on a combination of:

The screen reader software (NVDA, JAWS, etc.);

The speech synthesizer being used with the screen reader (eloquence, eSpeak,, etc.); and

The context (word, sentence, document, app, browser (IE, Firefox, Chrome, etc.) as some screen readers function differently in different user agents.

Running tests with different AT/browser combinations and comparing them to what you know about your users (e.g., Mac, PC, browser preferences, etc.) should give you an idea of whether the problem is widespread or more isolated.

It’s also important to note that changes that you make to force a pronunciation on a screen reader may introduce errors for those reading on a refreshable Braille display with their screen reader. For example, if you put spaces between characters or write out a word phonetically as you want it to sound but spelled incorrectly these errors will be very obvious to users of screen readers who also use a refreshable Braille display.

For example, an off-screen label for ViP might be “V I P” to get a screen reader to say VIP correctly. With a letter like “A” that can be pronounced “Ay” or “Ah,” adding the extra letter in the off-screen label may provide spoken clarity (e.g., “Ay D A” vs. “Ah D A”), but in Braille will be incorrectly spelled and will likely cause translation errors for people who use contracted Braille where groups of letters may be combined in a shorthand style.

Options for Forcing a Pronunciation from a Screen Reader

Current solutions are either not elegant or not well-supported. Non-elegant solutions are generally not encouraged, however, below are some suggestions (when necessary) for forcing a pronunciation on a screen reader.

Keep in mind that most of the time, organizations want to keep the on-screen text looking the same and so the modified pronunciation indented for the “screen reader” user would be included as text position off-screen with CSS or perhaps as an aria-label or via some other technique such as title or alt text when on a supporting control.

Space It Out

Let’s say you want the screen reader to say ABSCU with separate letters, and not “abscu.” you could add spaces to an abbreviation (“A B S C U”) or added letters to make an acronym pronounced correctly. However, as mentioned a user with a Braille display would see that text.

Aural CSS

CSS3 Speech seems like the best way to address this, but currently it is only supported by VoiceOver on iOS. Potentially, with aural CSS, you could have a screen reader spell out the digits of a number or speak “street” instead of “st,” but this isn’t well supported at the current time.

Options include but are not limited to, spelling out text character by characters, speaking numbers as digits, and literal punctuation to speak out all punctuation characters.

CSS Code Example:

<style> .address, .phone, .zip {speak: digits;} code {speak: literal-punctuation;} .spell-out {speak:spell-out;} </style>

You can check out an example of Aural CSS with your iOS device here.

ARIA Labels

As mentioned earlier, this isn’t an elegant solution and employs the same “hack” with spaces, capitalization, or phonetic spelling, but you can use ARIA labels to attempt to force a screen reader into a particular pronunciation. General the aria-label solution only works on interactive elements or content referenced by interactive elements such as with the label element or aria-labelledby.

Example:

<label for="zip" aria-label="zip code">ZIP Code</label> <input type="text" id="zip" >

The Better Solution

In general, when abbreviations or acronyms are used it is best to define them in text when they are first used. While you should use the abbr element—which takes a title attribute to provide an expansion—keep in mind by default, this expansion text won’t be announced by most screen readers.

For other situations where the pronunciation, punctuation being perfect is not required don’t do anything special and let the screen reader user use the screen reader commands if they want to verify the pronunciation. Screen readers come with commands to spell the current word by letters and even can speak each letter phonetically – these are well known and long existing commands that screen reader users should be familiar with.

For some situations such as assessments where a particular pronunciation is absolutely necessary for the assessment to be fair, use the methods described above and provide flexibility to the user in case they want to choose which mode to use. Test with different screen readers, speech synthesizers, browsers, and platforms to make sure that any solution is accessibility supported.