Musings

<abbr>, <acronym>, Accessibility & Automation

Nothing seems to sow more confusion among markup geeks than the proper usage of the <abbr> and <acronym> elements. Many discussions get sidetracked by the arcana of English grammar (“initialisms” versus “contractions” versus …) rather than focussing on the real issues. HTML is not English, and one should not confuse a discussion of the one with a discussion of the other. In HTML, these elements play two important roles:

1. Provide a definition of the term via the title attribute, as in

   <acronym title="Friend Of A Friend">FOAF</acronym>
   <abbr title="Cold Dark Matter">CDM</abbr>

   In addition to helping out readers who may be unfamiliar with the term, this can be useful to Search Engines (by informing them that a page making frequent reference to “CDM” is actually related to pages talking about “Cold Dark Matter”).
2. Provide a cue to screenreaders (or other assistive technologies) as to whether the term should be pronounced or spelled-out. This might be made explicit in an aural stylesheet

   abbr {speak:spell-out;}
   acronym {speak:normal;}

   or it might be implicit in the rules used by the screenreader.

If the only purpose were to provide a definition, there would be no point in having two distinct element which serve the same function. And, given that there are two elements, it wouldn’t much matter which one you used. On the other hand, if these two elements are to be treated differently by aural browsers, then, on Accessibility grounds, you should be mindful of using the right one in each case.

Which brings us to the next point. For the purpose of providing a definition, it suffices to mark up the first occurrence of an acronym or abbreviation on the page. It’s somewhat annoying to see a page littered with dotted underlines (indicating the presence of a tooltip giving the definition) on each and every occurrence of an abbreviation. Indeed, the WCAG says you only need to provide the definition at the first occurrence on the page.

But that’s not quite the same thing as saying you don’t have to mark up subsequent occurrences at all. Providing cues for screenreaders surely requires marking up all occurrences on the page. (I imagine that this might also help Search Engines, but that’s purely hypothetical.) The best way to achieve these varied goals is, the first time you use the abbreviation, to give its definition, <abbr title="Cold Dark Matter">CDM</abbr>, but on subsequent uses, to merely mark it up as <abbr>CDM</abbr>. This will satisfy the screenreaders, and can be hidden from visual browsers with code like

abbr, acronym {border:none;}
abbr[title], acronym[title] {border-bottom: 1px dotted black;}

Marking up all those abbreviations and acronyms by hand is pretty tedious. Which is why I recently installed the acronym plugin for MovableType. It uses a flat-file database, acronym.db to hold the definitions. It only supports the <acronym> element, but it is trivial to hack it to support <abbr> as well (with two separate databases, acronym.db and abbr.db). If you prefer the old behaviour, you can just put all your definitions in the acronym.db. Since it’s reasonably well-written, getting it to add a title to only the first instance of an acronym/abbreviation in each blog entry was also fairly straightforward. Once it’s installed, you activate it by adding the attribute, acronym="1", to any MT container tag (like <MTEntryBody>) and rebuild.

Anyway, here’s my patch to the acronym plugin (patch < acronym.pl.diff). You need to install the patched plugin and two data files, acronym.db and abbr.db (the latter can be empty, if you wish, but must exist), in your plugins directory.

One note of caution: the plugin is very fast because it doesn’t retokenize after each acronym/abbreviation substitution. This has an unfortunate side-effect. Don’t put other acronyms/abbreviations as part of the definition text in your database!

P.S.: Some people contend that, since Internet Explorer doesn’t understand the <abbr> element, you shouldn’t bother doing the right thing. There are two obvious responses: you could use a Javascript solution, or you could just not worry about it. Since it seemed to me that IE users need all the help they can get, I decided, in this case, to go the Javascript route. Besides, the idea of using crufty Javascript hacks to service a crufty browser seemed … only fitting.

Update (9/12/2003): I should have made an obvious point. If your page is sufficiently complicated and has multiple entry points, a visitor may not enter the page at the top, and hence might miss the definitions found there. In that case, it may not suffice to define each abbreviation once per “page.” It would be more usable to define it once per “section.” (You can see this on my blog’s main page, where each post is a separate section, vis-a-vis marking up abbreviations.) Also, you’ll notice that I haven’t enabled automated abbreviation markup for comments. Some people think that that’s a “service,” but if you leave a comment on one of my posts that says, “Jacques, I think you have succumbed to Steve Jobs’ infamous RDF.” I don’t think you are going to want that to be automatically marked up as “RDF.”

Update (10/29/2003): The patch has been updated to match version 0.5 of the plugin.

Update (12/20/2003): The patch has been updated to match version 0.6 of the plugin.

Update (2/13/2004): The patch has been updated to match version 0.7 of the plugin.

Update (5/28/2004): The patch has been updated to match version 1.0 of the plugin.