WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Forcing screen reader pronunciationofabbreviationimportant to a brand


From: KellyFord
Date: Apr 23, 2018 9:27PM


One thing to keep in mind, any solution that changes the text, such as inserting spaces, runs the risk of causing a poorer reading experience for users who are working with Braille. Those spaces will likely be present in the Braille text.

This could also cause confusion if a speech user wants to know the spelling of the text and starts reading by character. They will then perceive that the word is written with space characters and could mistakenly reproduce that error when they go to write the word themselves, if they want to refer to this same brand for example.


-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Bryan Garaventa
Sent: Friday, April 20, 2018 12:51 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Forcing screen reader pronunciation of abbreviation important to a brand

As others have already pointed out, I don't recommend this except in some very rare circumstances.

ARIA was mentioned as a fix for this, but the recommended ways of doing this may be problematic across various platforms where support levels differ, so here is one that works more reliably.

The trick here is to use aria-owns to change the accessibility tree without impacting the DOM, like so. This changes "BEG" to "B E G", however it has no impact on the DOM or the styling of the visible text.

<b aria-owns="space1">B</b><b aria-owns="space2">E</b><b>G</b>

Then the following can be appended to the end of the body element so nobody will notice it.

<i><b id="space1">&nbsp;</b><b id="space2">&nbsp;</b></i>

This appends a space character at the end of the B and E letters in the accessibility tree, and this is what causes the separation to occur between them.

A few notes about this: Unlike other ARIA attributes like aria-labelledby or aria-describedby which can reference hidden elements, aria-owns doesn't work like this and won't render hidden elements. Also this technique should never be used on elements that don't support children like IMG elements or input elements, because this forces the accessibility tree to change and any content that is referenced like this will disappear and become impossible to navigate and interact with normally. Also using this method should never be used to move focusable interactive elements around because this does not change the tab order. The use of aria-owns cannot reference the same ID from different attributes, so each referenced node has to be different as shown above.

All the best,

Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
415.624.2709 (o)

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of JP Jamous
Sent: Friday, April 13, 2018 8:53 AM
To: 'WebAIM Discussion List' < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Forcing screen reader pronunciation of abbreviation important to a brand

You can accomplish this by various ways. It depends on the situation you have at hand. The bottom line is you use ARIA to hijack the HTML element. It may not be the best method from a semantic prospective, but it gets the job done.

For example if I have a paragraph:

You have purchased NE1254 for $300.
You can hijack NE1254 using ARIA.

You have purchased
<span aria-label=" N E 1254">
for $300.

I hope that helps.

JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of JR Accessibility
Sent: Friday, April 13, 2018 8:55 AM
Subject: [WebAIM] Forcing screen reader pronunciation of abbreviation important to a brand

Is it possible to force a screen reader to pronounce a two-letter abbreviation a certain way, rather than the way the screen reader software wants to pronounce it?

In a previous WebAIM discussion from 2014, Geri Druckman suggested using the HTML <abbr> tag, but I cannot get that to work.

For the sake of example suppose my company's name is Nova-Echo but we go by NE (which should be pronounced 'N E') in our product numbers and in our preferred customer program, MyNE (which should be pronounced 'My N E').

The default pronunciation of the letters 'N' and 'E' next to each other in NVDA is 'northeast' and in JAWS it is 'knee'. This leads to undesirable pronunciations of our product numbers, such as 'northeast 1234' or 'knee 1234', and of our preferred customer program 'my northeast' or 'my knee'.

How can we force the screen readers to pronounce these items the way we want them to?

I have placed some sample HTML on my Google Drive, that contains additional

Also a spreadsheet with the pronunciations I observed in NVDA and JAWS:

Thank you very much.