Presenting abbreviations and acronyms for screen reader users

By Graham Armfield | 11th July 2017

Acronyms and abbreviations are all around us. Some are well known – such as BBC (British Broadcasting Corporation) and Satnav (satellite navigation), but others are less well known – for example HMRC (Her Majesty’s Revenue and Customs) and tsp (teaspoon). But what’s the best way to present these acronyms and abbreviations in a way that everyone can understand them?

One approach would be to spell out in long form version in plain text every time. But that can quickly get very verbose, and then there’s almost no point in using the abbreviations or acronyms.

The difference between abbreviations and acronyms

My take on the difference is that abbreviations are usually a short form of the full length word or words. For example: ‘Weds’ which represents Wednesday, or ‘satnav’ which represents satellite navigation.

Acronyms, however, are formed of a series of initials which represent all or some of the words in the thing or organisation that is being referred to. For example: ‘ARIA’ represents Accessible Rich Internet Applications.

In some situations, the short form can be made up of both acronym and abbreviation – for example ‘CAMRA’ which represents ‘The Campaign for Real Ale’. So the situation is not always clear cut.

Can HTML elements help us here?

HTML (itself an acronym of course) is used to present our content on web pages. There are a number of semantic HTML elements which help structure the content into manageable chunks – paragraphs, headings, etc. Assistive technologies like screen readers can use the semantics to explain to their users what is represented so that content makes sense.

For some time in HTML there has been an <abbr> element that can be used to represent abbreviations. The suggested use is to contain the abbreviation between the start and end tags, and to supply the full length version in the title attribute. For example:

<abbr title="Campaign for Real Ale">CAMRA</abbr>

But what about the <acronym> tag?

In HTML4 the <acronym> element could also be used to define acronyms. But in the HTML5 spec, the <acronym> tag has been deprecated in favour of <abbr>. So although many browsers may still support it, there is no guarantee that they will in the future. So it’s best to say goodbye to that one and just use <abbr>.

Where does <dfn> fit in?

I must admit I’d overlooked the <dfn> tag until I was researching this article.

According to the HTML5 specs, the <dfn> element is to be used for the ‘defining instance of a term’. The examples in the spec show it being used in conjunction with the <abbr> element – as follows:

Now, <dfn><abbr title="Accessible rich internet applications">ARIA</abbr></dfn> attributes can help give assistive technologies more information about custom components.

Then subsequent references to the abbreviation or acronym just use the <abbr title="whatever"> portion without the <dfn> tag.

I’ve never seen this actually being used within a web page – apart from the HTML5 example.

Screen reader support for <abbr> and <dfn>

During recent experiments, most screen readers it seems have some kind of support for <abbr>. The results are amplified below.

JAWS with Internet Explorer 11

When using JAWS with the default settings, abbreviations and acronyms are just announced in the short form – without any reference to the <abbr> tag and the contents of the title attribute within it.

However, there is a user setting within JAWS to expand abbreviations. Once this checkbox is checked, JAWS will always voice the long form of an abbreviation using the information obtained from the title attribute of the <abbr> tag.

Summary: Full support if user chooses.

NVDA with Firefox

When reading content normally, NVDA seems to ignore the <abbr> tag and just read out the shortened form of the abbreviation.

There is no user setting to force NVDA to expand abbreviations by default, but there is a rather tortuous way to get NVDA to voice the expanded form:

  1. Using up and down arrow keys, move to the segment of text that contains the abbreviation.
  2. Use the right arrow key repeatedly until you are within the abbreviation.
  3. Press the NVDA key + Num Pad 5 to report information for the current navigator object. NVDA will now announce the expanded form of the abbreviation – assuming it’s been marked up with a title attribute.

Whether most NVDA users know about that trick is a separate issue that I’m not going to cover here.

Summary: I’ll just say that NVDA has poor support for the <abbr> tag.

Voiceover on Safari on iOS10

Voiceover seems to have no support for the <abbr title="whatever"> construct, and so will read out the short form of the abbreviation – although the abbreviation itself will become a separate element when swiping through the content.

As far as I am aware there are no settings to allow abbreviations to be voiced in full.

Summary: No support.

Talkback on Chrome on Android 6

By default, Talkback announces the full form of any abbreviation that is enclosed in an <abbr title="whatever"> tag. There appear to be no user settings to change this.

Summary: Full support.

Screen reader support for <dfn>

None of the screen readers I tested had any kind of support, or behaved differently for <dfn>. But as we’ll see shortly the <dfn> tag could be useful – so let’s not ditch it just yet.

Abbreviations – support for sighted users

Screenshot showing the default dotted underline beneath abbr elements in Firefox

Note the dotted underline beneath the <abbr> element in Firefox

By default, some browsers style the contents of the <abbr> element with a dotted underline. It’s a kind of undocumented standard. Firefox and Chrome do this on desktop and mobile, but Internet Explorer and Safari on iOS do not.

Still it’s an easy job to update CSS to change or add some styling so that sighted users can see when an abbreviation is present.

Given that the <abbr> tags contain a title attribute, sighted mouse users can see the expansion of the abbreviation as a tooltip when they hover over the abbreviation.

However, that doesn’t help sighted keyboard users, or people using touch screen devices. For them, the title attribute stays invisible, so there is no explanation of the abbreviation.

It seems that for sighted keyboard and touch device users, having the expanded version of the abbreviation visible is the only viable option.

An alternative solution using CSS stylesheet techniques

However there is a CSS technique that could help here – using the content property to retrieve the value of the title attribute.

For example:

abbr[title]::after {
   content : ' (' attr(title) ')';
}

The content property is supported by all modern browsers, and in this example it causes the expansion of the abbreviation to be surrounded by brackets and placed into the content after the abbreviation.

But having the abbreviation expanded every time may be considered by some to be too much. How about if there was a way to reveal the expansion for the first instance of the abbreviation only?

Well let’s look again at the HTML5 spec for the <dfn> element – which says <dfn> should be used for the ‘defining instance of a term’. So we could use these semantic elements to govern the visibility of the expansions for the abbreviations.

So if in our HTML for the first instance of an abbreviation we used this…

<p>I'm a member of 
<dfn><abbr title="Campaign for Real Ale">CAMRA</abbr></dfn>.</p>

and for subsequent uses…

<p><abbr title="Campaign for Real Ale">CAMRA</abbr> 
membership has many advantages.</p>

and in our CSS we had this…

dfn > abbr[title]::after {
   content : ' (' attr(title) ')';
}

we’d end up with the expansion being visible for the first instance of the abbreviation only.

Screenshot showing default appearance for dfn, abbr and title attribute shown after elements in Firefox - italic text, with dotted underline, with the expansion being present on the screen.

Here the contents of the title attribute is printed onto the screen after the abbreviation.

But now we’ve catered for sighted users with a different approach, what about screen reader users?

JAWS with Internet Explorer 11

JAWS with default settings seems not to voice content contained in the ::after property. So JAWS just voices the short form of the abbreviation. When the option to expand abbreviations is selected, JAWS will always voice the expanded form.

NVDA with Firefox

NVDA voices the abbreviation plus expansion on initial instance, but just the abbreviation on the subsequent one.

Voiceover on Safari on iOS10

Voiceover voices the abbreviation plus expansion on initial instance, but just the abbreviation on the subsequent one.

Talkback on Chrome on Android 6

Talkback always announces the full form of any abbreviation that is enclosed in an <abbr title="whatever"> tag. It does not voice the actual abbreviation itself.

Conclusion

Satisfying everyone’s needs around abbreviations on web pages, and what they stand for, can be a bit of a challenge as there is no consistent approach to abbreviations from the screen readers I tested.

Using the CSS content technique outlined above certainly helps NVDA users on Windows, and Voiceover users on iOS since they get to hear the abbreviation and the expansion in context the first time they appear on a page. A better experience than not using the content approach.

Was this useful?

We hope you found this useful. If you think you could benefit from advice on your projects to help resolve issues like this one, or training for your digital project teams, please contact us.