I was pointed at some advice this week that was telling developers not to worry too much about using the abbr or acronym HTML elements. The reason given for the advice was lack of support for these elements from screen readers. There are certainly a few things to consider when using these abbreviation elements, but lack of support in screen readers is not a valid reason to forget about them. Besides the fact that their use is of benefit to more than just screen reader users, screen readers do actually support abbr and acronym.
The abbreviation elements have confused developers for some years now. I thought I’d try to clear things up a little with some information about how modern screen readers support and handle abbreviations.
What are the abbr and acronym elements?
The W3C quite simply tells us:
The ABBR and ACRONYM elements allow authors to clearly indicate
occurrences of abbreviations and acronyms. […] The title attribute of these elements may be used to provide the full or expanded form of the expression.
Differing opinions on the definition of an acronym sparks debate about how to use the elements correctly. Juicy Studio has an in-depth look at the confusion surrounding abbreviations that’s well worth a read if you want some background on that. Essentially, it’s debated whether an acronym is always spoken as a word (e.g. NATO) or may sometimes be spoken one letter at a time (e.g. FBI). If you ask the W3C, both examples I’ve just given are acronyms. Grammarians will often say that an acronym should be pronounceable as a word, demoting FBI from acronym status. This leads to confusion when trying to decide when to use acronym in markup. However, most people will agree that an acronym is a form of abbreviation.
A common approach to marking up abbreviations
One approach, which is often quoted as the best approach, boils down to practicalities of pronunciation and the technology involved rather that who wins the argument over grammatical considerations.
In theory, the acronym element could be used to distinguish between those abbreviations that are usually spoken as a word and those that should be spelled one letter at a time. In practice, this is not the case. I used this approach too until I began researching how abbreviations work in JAWS several months ago and changed my mind.
Abbreviations are supported in JAWS and Window-Eyes, which I’ll come back to in a moment. What JAWS does not appear to do is use the difference between abbr and acronym to inform how it speaks. I’m not sure about Window-Eyes having not tested it – yet!
Instead of differentiating between the elements, screen readers analyse words to determine whether or not they can be spoken as a word (using lexical analysis) – they don’t know whether or not it should be, so they guess. Screen readers may use the different elements to inform their analysis of words, but I haven’t found research to support that.
Aural style sheets could be used by a developer to specify the required pronunciation, but near-zero support for aural style sheets puts a damper on that one.
So, in fact, it actually doesn’t matter one way or another which element you use. Since, an acronym is a form of abbreviation and screen readers don’t seem to pay any attention to which element you use in your markup, I don’t use acronym at all any more.
It’s probably a topic for another time, but I currently use something along the lines of <abbr class="acronym"> where a plain abbr doesn’t quite scratch the itch. It allows me to classify an abbreviation, should I wish to do so, and provides a useful hook for applying aural CSS, should it ever enjoy a good level of support. XHTML 2.0 even drops acronym in favour of using abbr. Even though XHTML 2.0 is still a draft, hopefully it means I’m along the right track.
Accessibility myth: screen readers don’t support abbr and acronym
Interpretation of “support” for abbreviations depends on what you’re expecting the abbr and acronym elements to do for you.
If you’re expecting all words marked up as acronyms to be pronounced as a word and all others letter-by-letter, you’re out of luck. Screen readers will do their best to figure out what should and shouldn’t be read as a word. If the screen reader gets it wrong, a user can tell it to stop, go back over an offending word pronouncing it one letter at a time and then continue with the text. For common problem words, a user can set an entry in their screen reader’s custom dictionary that specifies a personal preference for how a particular abbreviation should be spoken.
But there’s more to it than pronunciation alone. The second half of our W3C quote gives us another use for the abbreviation elements.
The title attribute of these elements may be used to provide the full or expanded form of the expression.
A bit of Googling suggests that JAWS and Window-Eyes, two of the most common screen readers, have been able to speak expanded abbreviations marked up with abbr and acronym since 2003, when JAWS was in version 4.51 and Window-Eyes was in version 4.5. Older versions of these screen readers did not have this support for abbreviations.
In JAWS, the user can configure whether or not the software speaks the expansion provided by the title attribute in place of the abbreviated form. This can be found under the Verbosity settings HTML Options in the Configuration Manager (seems to have been removed from the Verbosity settings in JAWS 9.0). I know that Window-Eyes has similar options, but I’ve not tried them myself.
My own testing, primarily with JAWS, has found the options to work in recent versions. However, I have identified a couple of quirks with abbreviations in JAWS 7.10 and JAWS 8.0 that are worth noting. The settings for abbreviations haven’t worked properly in certain versions, but support has been around for quite a while and seems fairly stable now.
Another thing worth mentioning: don’t get tripped up by thinking that Internet Explorer’s lack of support for the abbr element in version 6 and below means that screen readers can’t use them. If you’re thinking, “Surely screen readers sit on top of a browser and if the browser doesn’t support something, the screen reader cannot either?” you’re about to learn something new. As the saying goes: “There’s more than one way to skin a cat!” Screen readers don’t rely on the browser’s document model for everything – they can use other ways to access the information they need.
Please be careful
So, there you go. Make of that what you will. If you want to know more about using the abbr or acronym elements in your markup, stay tuned!
I’ll close with a plea – please be careful when giving advice or publishing research!
While many people like short and sweet advice, I don’t like seeing information touted as “fact” without evidence – I see it too often in the papers (I say with a wry smile). If you’re going to provide advice to people, be able to back it up with links so that people can find out more. If you don’t, confusion breeds and gives birth to myth.
14 Responses to “Screen readers and abbreviations”
Jon, great, detailed, well-researched write-up as always. I would of been interested to see where the less-than-perfect advice was published though. Any chance of citing the source of the advice?
Thanks, Jon. Someone on Accessify Forum mentioned that they had read the advice in an article by Webcredible.
The forum member had been led to believe that
abbrandacronyminformed screen readers about how they should pronounce abbreviations. As I mention above, this isn’t the case.The article is actually right in as far as marking up abbreviations is a low priority in comparison to other accessibility guidelines. However, the article is wrong to say that “most screen readers” do not support
abbrandacronym. To say “most” is not clear and the two most commonly used screen readers (U.S. market estimates, NFB, 2003: 65% JAWS, 35% Window-Eyes) do support the elements. Perhaps the elements just don’t do what the author of the article expected?Marking up abbreviations with
abbroracronymtags doesn’t imply how the abbreviations should be pronounced. A difference in opinion over what defines an acronym is probably enough to make it unsuitable to giveabbrandacronymthe job of determining pronunciation. Instead, it’s a more appropriate job for aural CSS, which is poorly supported. The abbreviation elements are pretty good at their other job though; that is, to provide the expanded version of abbreviations.Good to know about support being available when used with IE6. Like many people I was under the impression that the abbr wasn’t recognized. Thank you.
I try to expand them as real text now, as in: abbreviation (abbr). First instance, anyway. My feeling is that everyone gets the goods that way, and in the same way, but I try to keep it natural sounding. I do use all methods, though, depending on the situation. However, it is important to use the elements. For a time when they are treated properly… in the future.
My definition is: Abbreviations are of two types, the more common abbreviation and the specialized acronym. Both are typically comprised of initialisms, but not always. (More so as it concerns acronym-type abbreviations.) A definitive way to tell them apart, in my eyes, is that acronym-type abbreviations can and typically are spoken as words instead of spelled out.
I stick to that as a hard and fast rule when applying the elements. It takes the guesswork out of it first of all (good for consistency). Second thing is I think we will see better support for the elements in the aforementioned future since that is basically how it’s defined in the working draft of the WCAG 2: http://www.w3.org/WAI/GL/WCAG20/#abbreviationsdef
Thanks for your comment, Mike.
I’m in two minds as to whether there is any value to having two separate elements at all.
We can cover each eventuality with
abbrand use theclassattribute to differentiate where appropriate and apply CSS. Theoretically, having two different elements can help assistive technology to better understand without the need for CSS. So, two elements?Obviously, aural CSS enjoys little to no support, thus having the two elements is probably of little value in terms of pronunciation. Since the elements have caused developers such confusion over the years, implementations aren’t consistent and cannot be relied upon. So screen readers get by with what they know and, to my knowledge, without any help from our
abbrandacronymelements. I’m back to just using one element:abbr.I guess I am hoping that once the draft becomes a recommendation, Jon, makers of screen reading software will provide support for both of the elements through they normal upgrade cycle. Even though it’s sort of futile now, they do serve a good purpose if only the support was improved to meet the specification.
Better aural style sheet support would be nice, too, since we could really customize the user’s experience. But if at least the minimum was provided — meaning speak acronyms and spell-out abbreviations by default — our use of both will be useful. And since the rule is very matter-of-factly written, it would be easy for all developers to be on the same page with element implement as well.
And now, thanks to your research and that we now know IE6’s lack of support isn’t a detracting factor… well, it’s almost liberating.
Bummer for the visual IE6 users who must rely on title attributes, they won’t get the goods. But if the first instance is expanded as real text everyone’s served so even that becomes an moot point.
—
I must admit, when I first read your article I was thinking to myself: Yikes, I hope it isn’t me who wrote the ill-advising article he’s talking about. I was feeling guilty, perhaps, for I was unknowing about the IE6-override. :-/
Actually, while I know that there’s more than one way that a screen reader can get information from a document, I’m not so sure that screen readers need a workaround to access
abbrelements after all. I’m going to do a bit more testing to be sure.Regarding having two elements for abbreviations: You’d think it’d be easy for developers to get it right, but you’ll know as well as I do that they often don’t. I wonder if there are still people out there who only ever use
acronymbecause of IE’s support issues.Screen reader vendors will be concerned with making things work for their customers now. Screen readers currently do support both of these elements; they just don’t use them to inform how words should be pronounced. I’ve never actually seen it stated that
abbrandacronymshould be used by screen readers to inform pronunciation – it’s only ever been implied through grammatical convention. WCAG, HTML, UAAG – none of these actually tell screen readers to do anything other than allow access to thetitleattribute. There’s not necessarily any need for improvement as far as W3C Recommendations are concerned.> I wonder if there are still people out
> there who only ever use acronym because
> of IE’s support issues.
I think the ALA does that actually. I recall reading that in the submission guidelines.
Just took a look. The ALA style guide suggests using
acronymfor marking up abbreviations pronounced as words andabbrfor everything else. Strangely under punctuation rather than grammar, though!On a related note, I found examples of abbreviations in the Techniques for WCAG 2.0 Working Draft that seems to suggest that
acronymis still not reserved for abbreviations pronounced as words. According to the W3C,acronymshould still be used for initialisms.A lot of places suggest only adding a title to the first instance of an abbr/acronym. Do you know if screen readers will re-read the original title on subsequent title-less instances of the same abbr/acronym?
FP: No, screen readers do not replace subsequent occurrences of abbreviations in the way you describe. They will only speak the expansions if a title attribute exists on the abbr/acronym element and the user has told the screen reader to read expanded forms in place of abbreviations.
While technically possible, the main reason that software doesn’t guess at the meaning of abbreviations is due to the difficulty in disambiguating abbreviations that may look the same but in fact have different meanings. It may not be particularly common, but you might have something like this contrived example:
Our cat (feline <abbr title=“category”>cat.</abbr>) got a <abbr title=“computed axial tomography”>CAT</abbr> scan.On a related note, I don’t actually see why only putting a title attribute on the first occurrence of abbreviations is recommended by people. It is useful to expand the first occurrence of an abbreviation in a body of text (i.e. not hidden in a title attribute), but if abbr/acronym elements are useful at all, they should surely all have title attributes.
Thanks for the information dotjay.
Perhaps a situation where it might be OK to only use a title on the first abbr/acronym is if the abbreviated form is more common than the full form (e.g. BBC or HTML).
@FP: It depends on whether you think the content of the
titleattribute is meant to supplement the abbreviation or to be an alternative to the abbreviation. Screen readers treat it like analt—it is read out in place of the abbreviation—which is not strictly in line with whattitleattribute is for.A question I hope to be able to answer soon is: Are abbreviations more useful to screen reader users when they are read out in full every time or just the first time they are used?
Nice post keep the good working
Additional research on assistive tech compatibility for abbr can be found at:
https://www.powermapper.com/tests/screen-readers/labelling/acronym-abbr-title/