Acronym vs. Abbr!

A long debacle has plagued the web standards community: that of ABBR vs. ACRONYM.

Let’s get one thing straight, to begin with: an acronym is still an abbreviation. Everything that is a contraction of a fuller version is an abbreviation. Acronyms, initialisms, 2nd-class-initialisms, communist-initialisms – they’re all still abbreviations.

HTML tags exist for the purpose of alerting the user agent to do something different. CSS exists to illustrate to the user how things are done differently.

This means that use of abbr at a base level is more than enough, because the user agent (including assistive technology) is aware that the content within the tags is not to be treated as standard text, and it can therefore work out from the tag you used what your intention was. A screen reader relies on an extensive dictionary to be able to pronounce any word, and it will/should rely on this dictionary to work out whether it feels a set of characters, marked up as an abbreviation, should be pronounced in a different way (either as letters, or as a word but with the option of also saying the expanded meaning).

Where there is ambiguity, there will be ambiguity for everyone, and so the content author should learn to write content better. (for example, logically, IE and i.e. could be equivalents, depending on the individual and/or the localisation norm. But it may seem clear to the content author which is which).

Assumptions will always have to be made about the user, and the user agent, analysing content. That’s why well written content will also include an expansion of an acronym/initialism in parentheses, unless it can be safely assumed that the anticipated audience will already have this knowledge. The benefit in expanding etc. into etcetera by use of any tag is slim, since it still makes the assumption that the user knows what etcetera means, that the user-agent/AT will be better at saying/reading etcetera than it will be by intelligently interpreting etc. and it makes the assumption that AT developers aren’t capable of making the technology intellegient and/or localised, with UK and US dictionaries usually being the first stage.

There is far too long a chain of possibilities to be able to reliably pick either ABBR or ACRONYM or another tag. You may use a colon to introduce a list, as you grammatically should, but another person may use a colon-hyper combo to do it. What are you able to do to ensure that the screen reader delivers the correct length of pause in order to indicate it’s a list? (and before you answer, do you really advocate marking up:

Western languages make extensive use of acronyms such as “GmbH”, “NATO”, and “F.B.I.”

into:

Western languages make extensive use of acronyms such as [ul class=”inline”][li]”GmbH”,[/li][li] “NATO”,[/li][li]and “F.B.I.”[/li][/ul]

and perhaps using CSS’ :before and :after to insert the commas and ‘and’s for a list item with the class ‘last’? Semantically, it’s a lot more meaningful and less ambiguous than what we had before.)

Anyway: there are too many nuances of too many languages, and dialects of languages, to be able to provide appropriate tags for them all. All that is required is for the content author to ensure that pieces of content which are not standard words – i.e. use formatting (capital initials) or punctuation (etc.) – are marked up to indicate to the user agent that something different needs to happen here. The user agent and the user themselves are then responsible for interpreting how this content should be broadcast. Use of localised assistive technology, with frequent dictionary updates to follow current language fashions and trends, would ensure that the user is receiving a reasonable interpretation of what the author is trying to say. It’s then up to the user to keep educated enough to understand what the user agent is offering to them.

Solutions? Gez Lemon suggests using this for print stylesheets, or for people with poor mobility in their alternative stylesheet:

abbr:after
{
content: ” (” attr(title) “) “;
}

Finally, on repetition of acronyms, users and UAs should handle this in their own way – if a user doesn’t understand an acronym because they’ve hit the 3rd usage of it, common convention (and the guidelines) will indicate to them that it might be somewhere else on the page, and so will be encouraged to look for it.

Either that, or they google it like I do when I don’t understand something. I then ignore the google results and click on the definition to go to dictionary.com, then click on the acronym link to go to acronymfinder.com. But that’s just for bandwidth abusers!

It’s entirely conceivable that a UA should provide a context menu for acronyms/abbreviations that give you a number of choices – one of these would be very simply to get the UA to look at the rest of the page for you, and identify the first (or better, previous to the current) instance of the acronym, and take the title from there. If it just shows you this in the menu, even better. Another option could be exactly the above – search for the acronym in the predefined website/dictionary of the user’s choice etc.

And we could end up with limitless resource and pamper everyone…. 🙂

Final word: use of the ABBR tag is the most generic possible in the current W3C specifications, and is the only one which should be used unless there is certainty that it’s an acronym as well. In this case, the abbreviation should perhaps be wrapped in both – a nightmare of tag soup, but the standards (and Microsoft’s absurd understanding of them) do not serve us well. Semantically neutral tags don’t really help us, because this is semantic. Ideally, duplicate the effort by providing the expansion of the abbreviation in an alternate form, so you’ve got all bases covered. Any comments from any users as to whether this has ever actually mattered to them, would be most enlightening to, and may help put the matter to rest….