Eons ago, Ian Lloyd caused a bit of a hoo-haa within the various web accessibility discussion lists. What had he done that was so controversial? Well, he had raised the subject of acronyms and abbreviations in HTML - a topic that regularly raises its ugly head and generally leaves more people confused afterwards. So, just what is the issue here, and what has it got to do with web accessibility? Ian explains.

The <abbr> and <acronym> tags are a very useful little feature of HTML4 (and above). However, they are not that well known, or certainly not within the less technical web designers and programmers out there. I believe this is partly because:

  • Very few HTML editors support these tags (by providing a toolbar button, for example). I have used various editors such as Homesite, Dreamweaver (version 4 and MX, TopStyle Pro and GoLive and not once have seen an option to insert an abbreviation or acronym.
  • People make assumptions,  based on their audience, that that an abbreviation or acronym is well-known anyway and needs no further explanation. Often this is true, but I can think of many sites that regularly use such abbreviations and I don’t know what they mean -  I just accept them as being some kind of programming term and move on.

A useful aid to understanding

You may be asking, “So, what exactly do these tags do then?”. In short (no pun intended), they offer you a facility for annotating an abbreviation but without necessarily bloating your document visually by repeating the full title in the body text over and over again.

This <abbr title="HyperText Markup Language" lang="en">HTML</abbr> and this is <acronym title="North Atlantic Treaty Organisation" lang="en">NATO</acronym>

The benefits of doing this for people browsing your sites include:

  • For people who do not know the abbreviation/acronym, a quick hover of the mouse over the phrase in question will reveal the full description in a tooltip
  • It saves having to create a separate glossary page and referring people to that page at each and every mention of an abbreviation/acronym
  • For people using Mozilla/Netscape 6+/Phoenix, the abbreviation/acronym is indicated on screen with a subtle dotted underline - a very handy feature for drawing attention
  • Your pages are more searchable to the likes of Google, Yahoo, Inktomi and so on
  • A screen-reader should be able to read out the full description of the abbreviation/acronym - a great thing for blind and visually impaired users of your site; for sighted users it is not necessary to repeat the full abbreviation/acronym on screen at every mention
  • If you start using it, so will others … and so will others. These are great tags (if you can get your head around them) - the more people see how useful it can be, the more we’ll see it being put to good use!

But,and there’s always a but, there are some problems with these tags.

The first one is that an audience that might benefit from it most � the blind and visually impaired, who may not notice the subtle dotted underline or be able to move a mouse over the abbreviation to view a tooltip � is scarcely catered for. Very few screen readers currently enunciate the title of abbreviation and acronym tags. However, this could be fixed in future versions, so my advice is to use this markup to ensure forwards compatibility.

The second problem is that the most used browser - that’s Internet Explorer on Windows - unfortunately does not support the <abbr> tag. It does support <acronym>, however. So, you can choose to generate only <acronym> tags, but you won’t be semantically correct as there is a difference between the two that you need to understand. It is wrong to simply label everything as an acronym just to satisfy user interface considerations in IE. This is where it starts to get tricky.

What’s an Acronym? What’s an Abbreviation?

Quick semantics lesson …

All salmon are fish but not all fish are salmon. This is unquestionable. A salmon cannot be confused with a perch (actually that’s a lie - I wouldn’t be able to tell the difference) but both are definitely fish. What am I angling for here?

With my fish simile still fresh in your head, I shall continue: all acronyms are abbreviations but not all abbreviations are acronyms. Confused? Let me explain …

  • An abbreviation is just that - a string of words that have been reduced in some way, or even a single word that’s been abbreviated (for example, btw meaning ‘by the way’). If the abbreviation is made up of the initial letters, it’s a particular kind of abbreviation known as an ‘initialism’ and each letter is read out:
    • NSPCC pronounced “Enn Ess Pee See See”, initialism
    • RNIB pronounced “Arr Enn Eye Bee”, initialism
    • Pro, truncation of professional
    • Info, truncation of information
  • An acronym is a special kind of abbreviation. Either by luck or design, the initial letters make up an abbreviation that can be read aloud as a word in its own right:
    • NASA pronounced “Nassa”
    • GUI pronounced “Gooey”

So, to decide whether you should use an <acronym> or <abbr> tag, use the test above - “Can I say the abbreviation as a word in its own right?”. If yes, use an <acronym>.

I don’t agree with your definition

What? You’re questioning me? Only kidding. However, you would not be the first to question that definition. If you read dictionary definitions, they do support the definition above. However, some of the help files and other tutorials out there on the web have misinterpreted the original specifications, and they often suggest using <acronym> for any abbreviation that is based on initial letters (or ‘initialism’ as you’ll recall). So, I will forgive you for taking issue with this me on this, but trust me, I’m not fooling you!

I say Sequel, You say Ess Kyoo Ell

So we’ve only just defined a method for working out when you use <acronym> and when to use <abbr> and what happens? SQL comes along backed up by his double-hard cousin SWF. Sequel? Swiff? What’s a screen reader to do? Because this is what’s at stake here 1000 ‘ mess up the definition and you won’t harm the on-screen display at all, but you can louse it up for any assistive devices that attempt to read out the abbreviation.

By marking up SQL as an <abbr>, you are giving instructions that it is not a pronounceable phrase. As such, each letter should be read out separately. You can reinforce this with Aural Cascading Style Sheets like so:

abbr {speak : spell-out;}

For acronyms, you will want the word read out as a word in its own right. After all, that’s what we’ve agreed upon as being an acronym, right? This, too, can be specified using Aural CSS:

acronym {speak : normal;}

So, if you incorrectly apply an acronym to something that definitely is not, the assistive device may attempt to read it out as a word and get the pronunciation completely wrong. How would it know that SQL should be pronounced ‘Sequel’? How would it know that Flash people pronounce SWF as ‘Swiff’? It could just as easily be ‘Swaff’, after all.

But hang on, what about ‘info’ or ‘pro’? These are abbreviations, aren’t they? According to the advice above, this would be marked up as <abbr> and then read out letter by letter (spell-out). I-N-F-O. Oh dear, this needs more thought.

Ben Meadowcroft details in his article how to resolve this by using two classes that you can apply to your abbr tags, like so:

<abbr title="Cascading Style Sheets" class="initialism">CSS</abbr>
<abbr title="Hyper Text Mark-up Language" class="initialism">HTML</abbr>
<abbr title="Europe" class="truncation">Eur</abbr>

Aural styling of these elements using CSS

acronym {speak : normal;}
abbr.initialism {speak : spell-out;}
abbr.truncation {speak : normal;}

Now then, back to the thorny issue of Internet Explorer’s lack of support for the <abbr> tag.

Spanning the standards-support gorge

There is a workaround that you can use to provide IE users with a tooltip. Unfortunately it does mean that you are duplicating markup somewhat, but you need to make the decision about whether this is more important, based on what you know of your audience. Take a look at the following code:

This is <abbr title="HyperText Markup Language" lang="en"><span title=”HyperText Markup Language” lang=”en”>HTML</span></abbr>

If you want to highlight the abbreviation on screen, you can then apply a suitable style using CSS:

abbr span {
font-weight:bold;
border-bottom:1px dotted #000000;
/* similar to the default styling in Gecko based browser such as Mozilla, Netscape 7 and Phoenix */

}

This could a little bloated if you have a lot of these phrases in your web page, but it’s worth considering. Alternatively, you can use a clever bit of scripting to do this for you automatically, as detailed by Marek Prokop in his article ‘Styling <abbr> in IE’

Conclusion:

I should be so lucky - if there’s one thing I’ve found out recently it’s that the difference between these two HTML elements will continue to confuse people, and the issue will raise it’s head again many times. In fact you may be reading this as a result of searching for answers following another newsgroup rally!

There is something you can do that should make it easier to take the brain-ache away. Take a look at the Acrobot tool over at Accessify. It was while building this tool, which converts your abbreviations and acronyms - that I unearthed all the inconsistencies and confusion that exist. I hope that having put everything together in this one article that most of these are now resolved. Heck, I’m going to bookmark this page for future reference!