This week’s question comes from Trevor Brennan.
How should someone markup the first instance of an acronym (within body copy) where its acronym directly proceeds its definition: eg. “Web Content Accessibility Guidelines (WCAG)” Obviously the following would be daft for screen readers: Web Content Accessibility Guidelines (WCAG) But if it’s text only and not an abbr tag than it’s against guidelines and likely a screen reader will try and pronounce “WCAG.”
Screen Reader Defaults
Providing abbreviation expansions in the
title attribute is “what we do,” but it does rely on the some customization of settings for some screen reader users:
- VoiceOver on the Mac reads
titleattributes by default
- Screen readers like JAWS and Window Eyes don’t read them by default
Whether or not people actually do change their settings is another question, but the fact that it is not a consistent default setting limits its potential.
Accessibility for All Users
But it isn’t just a consideration for screen reader users.
title attributes aren’t readily available to keyboard users. Hiding the expansion in the
title attribute does nothing for those users, which include many “groups” of sighted keyboard users — people with low vision and people with mobility or dexterity impairments, for example.
Fortunately, we can make abbreviations expansions more accessible to everyone. I’d use what you already have spelled out in your question, but reverse it. Here’s an example:
When crafting accessibility legislation, many countries around the world refer to the WCAG (Web Content Accessibility Guidelines) from the W3C (World Wide Web Consortium).
It is entirely acceptable to use this method of full expansion on the page to provide the meaning of abbreviations this way. I prefer the pattern where we provide the abbreviation first and then the expanded form after, rather than the other way around as you did in your example.
If we’re providing this expansion for the first occurrence on a page, the idea is that if the person consuming the page comes across another instance of the abbreviation later in the page where it isn’t expanded, they can search the page for the abbreviation and come across the expanded form.
Thinking in those terms, if we find the abbreviation using the browser’s search/find tools, and we list the expanded form after, we create a more natural reading order. If we write it as expanded form (abbreviation) then once the person finds the abbreviation, they need to move backwards rather than forward to get the expanded form.
As for this part of your question:
But if it’s text only and not an
abbrtag than it’s against guidelines and likely a screen reader will try and pronounce “WCAG.”
Well, you’ll be okay with that. It’s not really against guidelines — you’ve provided an appropriate mechanism to figure out what the abbreviation stands for. That’s about all you can do, and a totally accepted solution for meeting the requirements (see the details of How to Meet Success Criterion 3.1.4 below).
The screen reader is going to do whatever it wants with the text there anyway, even if you marked it as an abbreviation without a
title attribute. Besides, I’ve heard several different pronunciations of WCAG from real people: wuh-cag, double-you-cag, way-cag. We might as well add a screen reader’s interpretation into the mix :)