The Accessibility Hat Trick: Getting Abbreviations Right

by Colin Lieberman

39 Reader Comments

Back to the Article
  1. In the article, we are told that JAWS will read the title attribute of abbr elements, but will not read the title attribute for span or defn elements. Would I be correct in assuming that abbr and acronym are the only elements that JAWS will read the title tag if it is present? I am particularly curious as to what JAWS would do when it encounters a blockquote with a title attribute.

    Are there any other elements that JAWS would read the title attribute in place of the element? I can’t imagine that it would, but I would hate to find out that JAWS replaced the glossary at the end with the phrase “Site Glossary”.

    Copy & paste the code below to embed this comment.
  2. I can see one very big problem with the suggested glossary approach; if users (particularly screenreader users) follow a definition link to the site glossary (either to look up the term if they understand the link’s purpose, or because they are curious why that term is linked at all), they have no way of returning to the point on the page that they were reading.

    They would have to click the Back button, and then presumably either start from the beginning or switch to Links mode and move through all the links on the page until they find the one they just visited (inconvenient, especially if that term is linked more than once on the page).

    Copy & paste the code below to embed this comment.
  3. Instead of having a link class .gloss, why not just define abbr a to do what you want? Seems unlikely you’ll wind up with non-glossary links inside an abbr tag; if you do, you could always define a class for them.

    Copy & paste the code below to embed this comment.
  4. “Our first goal is compliance with XHTML 2.0.”

    What on earth for? XHTML 2.0 is currently only a work in progress. According to the latest spec “[it] is the seventh public Working Draft of this specification. It should in no way be considered stable, and should not be normatively referenced for any purposes whatsoever.”

    So why avoid the IE-friendly (and valid) <acronym> element, purely to support an unfinshed standard that’s not supported by any existing browser and whose own spec tells you not to use it. Given that the W3C are the only people on earth slower than the IE development team (any sign of them finishing the CSS2.1 spec?), I wouldn’t hold my breath waiting for XHTML2. Heck, we’ll be on to IE9 by then.

    There’s a lot of useful and thought-provoking stuff in this article, but it’s marred by this piece of gotta-be-on-the-bleeding-edge geekery.

    Copy & paste the code below to embed this comment.
  5. I will have to assume the article was mainly ‘theoretical’ and many of the techniques would probably clash. It’s fine for those who know what they are doing already. Though in the wrong webmaster’s hands they’ll believe Triple-A is just one single normative checklist, it didn’t help by referencing the WCAG 2.0.

    Parts of the article were useful but it appeared like it was hyping XHTML 2.0, which has hardly been completed. Some modern User Agents cannot cope with anything greater than HTML 3.2 in today’s world.

    Copy & paste the code below to embed this comment.
  6. …but it’s certainly worth mentioning that, taking the wording of WCAG 1.0 strictly, it’s practically impossible to achieve (and 2.0 is currently even worse, so much so that plans for revision include a different way of being able to claim AAA without needing to cover all p3 success criteria). just looking at priority 3 in 1.0, you have whoppers like “11.3 Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.)”. i can’t see any site being able to ever claim complete adherence to this. or how about “14.2 Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page”?

    oh, small typo: the english abbreviation for “limited” is “ltd.”, not “lmtd.”

    Copy & paste the code below to embed this comment.
  7. Very nice article. I think it’s a bit over the top to even support text-only browsers. It however proves that one can, which is pretty cool.

    I’m not sure though that the following isn’t semanticly correct:
    <dfn title=“see glossary”>root-mean-square

    Copy & paste the code below to embed this comment.
  8. Matthew Pennell raises a good point about a way back from glossary links. Alt + left arrow is JAWS’ equivalent of a back button, and it returns to the location of the referring link, from which the user can continue reading.

    Copy & paste the code below to embed this comment.
  9. Quote: “The assertion that abbr is structural is misguided, as the point of the tag is the content of its title attribute.”

    I have to disagree with that. The tag is structural – otherwise you would be using a span with a title attribute.
    Just because it doesn’t work well with screen-readers doesn’t mean it’s not structural… I don’t like the inference that the DOM is only there for user-accessability reasons.

    Copy & paste the code below to embed this comment.
  10. Using Opera 8.5, I cam across some interesting problems with some of your abbreviations.

    Specifically, the ones coded as, eg, <abbr title=”…”><span class=“caps”>WCAG</span></abbr>. These appeared with a dotted underline, but I could only get the tooltip if I moused-over the dotted line, as soon as the cursor moved over the text, the tooltip disappeared.

    I couldn’t even see a declaration for .caps – given that the content was typed in capitals in the source, what is the purpose of it?

    Copy & paste the code below to embed this comment.
  11. While it’s true that XHTML 2.0 isn’t yet a viable spec, I think there’s value in looking ahead — particularly when the spec-in-progress seems to be moving toward a good decision like the removal of the acronym tag.

    <acronym> will be with us for a long time yet. IE6 will not be eradicated at the drop of a hat (unfortunately!), and the fact is that using the acronym tag does work more readily for most current browsers than abbr does, once you have found ways to hack it to work in IE6 … only to find this breaks it in other browsers.

    So how about a mongrel … OK, so it wouldn’t be valid <acronym title=“eXtensible HyperText Markup Langauge”><abbr title=“eXtensible HyperText Markup Langauge”>XHTML</abbr></acronym> 2.0, but would nesting the tags like that work across different browsers?

    Copy & paste the code below to embed this comment.
  12. Excuse my ignorance, but in the original article and all subsequent posts, no one defined the acronym AAA.  Would someone be so kind as to give me a clue?  I’d appreciate it.

    Copy & paste the code below to embed this comment.
  13. Be careful with the links though, (13.1.2) as all anchor elements are required not to use the same link text to refer to different resources.

    Personally, I find this a very thought provoking article, but there is too much code for my liking… I will stick to providing support for the good browsers, and sod IE6, not worth my time catering for every one of its deficiencies (but don’t mind spending a few/many hours fixing its CSS bugs).

    Copy & paste the code below to embed this comment.
  14. but would nesting the tags like that work across different browsers?

    In theory, no. XHTML 2.0 is strict, strict, strict. That means you’d have to serve the page as application/xml and not text/html. Isn’t it supposed to be that the rendering of the page would then fail in a compliant browser since the page is technically an application and not a text file?

    Copy & paste the code below to embed this comment.
  15. As long as we’re speaking of abbreviations and semantics, that “e.g.” in the glossary should have the title “Latin; For the sake of example,” (or “Latin; For example”) rather than merely “for example.” I only say this because that is essentially what was done for the French term mentioned earlier.

    Copy & paste the code below to embed this comment.
  16. I agree with this statement.

    In the article, I noticed that there is a single use of “i.e.” that is served with a Latin language type, but the title attribute’s value is “that is”, but this was not done for “e.g.”. Why was this?

    Copy & paste the code below to embed this comment.
  17. The definition of RMS in the glossary is not quite right.  RMS is the square root of the average of the squares, and not the square of the average of the square roots.

    Copy & paste the code below to embed this comment.
  18. Once again, an article on accessibility seems to alienate most web pros. Indeed the greater the number of A s it’s trying to achieve the greater the reaction. This is because ‘accessible to all’ is an unreasonable, if not unattainable, goal.
    For instance, I would argue that the under-10 age group is a larger segment of web users than the disabled. Therefore, all web pages should be written in the style of ‘Janet and John’ books to make them readable by this group and, as a side-affect, those adults who are ‘literally-challenged’ though it will probably turn most of the rest of us off as well as making almost all the web sites I’ve ever visited inaccessible including this one. I fully expect the next issue of ALA to not contain any words with more than 3 syllables, if you’re serious.
    Having said that, I have no problem with making sites as accessible as possible to THE AUDIENCES THEY ARE AIMED AT. Indeed, I try to make my designs comply to double-A guidelines though I’m not quite there yet. My biggest problem is that I write in English, for an English speaking audience, but live in a non-English speaking country so I have to remember to use the LANG attribute whenever I use local placenames, real names, etc. and HREFLANG whenever I link to a local site.
    This article was useful for an insight into how a screen reader works, information that I have sought in the past without success, but what is really needed is an assistive-technology equipped browser (come on you Open Sourcers) that designers can use to test pages, as they do with the visual types, without having to fork-out the obscene prices that I’ve seen for currently available apps. That’s another thing! Perhaps instead of their tendency to bleat, organisations for the disabled should commission someone ( to write one. That would be a real benefit to their constituency as well as the people who produce the sites. In the meantime, we have to rely on, mostly contradictory, articles on accessibility or design to the technical standards and hope for the best.
    On a lighter note, you missed an abbreviation in ‘Mark W. Everson’. I want to know what ‘W’ stands for. It must be important or it wouldn’t be there.

    Copy & paste the code below to embed this comment.
  19. That’s true of Web Content Authoring Guideline (WCAG) 1.0, but there’s no such demand in the current Working Draft 2.0 (so far as I have found).

    In fact, conformance is defined relative to a technology baseline. AAA may not even require achieving all level 3 checkpoints.

    Which is just as well, because (despite this excellent article) AAA as it stands is either impossible or undesirable for any website that is aimed at a specific audience.

    Copy & paste the code below to embed this comment.
  20. Be careful with the links though, (13.1.2) as all anchor elements are required not to use the same link text to refer to different resources.

    No problem. You have
    <abbr href=“glossary.htm#css” title=“Cascading Style Sheets”>css</abbr> and <abbr href=“glossary.htm#html” title=“HyperText Markup Language”>HTML</abbr>, where the destination of the two links is different – what comes after the # does count.

    Copy & paste the code below to embed this comment.
  21. I think it’s funny that you never defined what AAA and JAWS are.  One can guess from context that AAA is some kind of standard for accessibility and that JAWS is a program that speaks the text of a Web page for the benefit of blind people, but you never say what they are or link to sites that explain them further…

    But A List Apart is for general Web design issues, not just those specific to your field, so you need to define these acronyms.  Especially when defining acronyms is the subject of the article!!!

    Copy & paste the code below to embed this comment.
  22. The W3C’s nomenclature is confusing. A conformance means that Priority 1 checkpoints are satisfied; AA conformance means Priority 1 and 2 are satisfied; and AAA conformance means all accessibility checkpoints are satisfied:

    Conformance Level “Triple-A”: all Priority 1, 2, and 3 checkpoints are satisfied

    The definition is from a “link”: at the very beginning of the article.

    See, the author did tell you.

    Copy & paste the code below to embed this comment.
  23. Yes, we were told, but in a way that’s pretty easy to miss.  Just because an accessability issue has been addressed does not mean it’s been addressed in an obvious or usable way.  Perhaps we need to create a new web design discipline, the usability of accessability.

    Copy & paste the code below to embed this comment.
  24. We editors failed to notice that the term had not been defined within the body of the article, or in an obvious, can’t-miss-it-way.

    For my part, I must have assumed that anyone who would read such a specialized article would be familiar with JAWS and with the W3C’s WCAG 1.0 conformance level nomenclature. It must have seemed to me that people who weren’t familiar with that level of arcana would have no reason on earth to read the article. (None of this would have been conscious. I’m reverse engineering my assumptions.)

    I regret that some readers felt left in the dark on these points.

    Copy & paste the code below to embed this comment.
  25. I didn’t need either explained to me in any more detail.  But I also didn’t need U.S. or Mr. explained to me.  Or to pick items from the actual body text rather than examples, I didn’t need IE or e.g. explained to me.  Doesn’t bother me one bit that they were coded for further explaination, wouldn’t have cared if they weren’t.  But, apparently, it makes some people feel witty and/or important to point out ironies, ommissions, or otherwise enter into intellectual pissing contests with ALA writers and staff (or so it seems to me, I’ll stick with my subject line and not speak for others).

    I was actually attempting to make a serious point about the difference between achieving compliance with accessability guidelines by following the letter of the law vs. the spirit behind them.  I’m sure I’m preaching to the quior with Jeffrey and Erin and Colin, and I’m not trying to say the failure of some audience members (myself included) to follow the introductory links provided and properly digest their content before diving into the article indicates a failing on the part of Colin or the ALA editorial staff.  It’s a perfect illustration of Murphy’s Law.  Every time you make something fool proof, you find a better fool. 

    We can look at this and try to look down our noses at professionals who write articles for ALA or otherwise try to contribute to the ALA community; or we can have a little chuckle and make a mental note that even with a site written and produced by professionals and with an audience comprised of professionals or otherwise educated insiders, slip ups can happen.

    This particular slip up was trivial and relatively unimportant given the target audience (knit picky lot we may be), but I do think it serves to illustrate the SNAFU (Situation Normal, All Fouled Up) principle pretty well.

    Copy & paste the code below to embed this comment.
  26. This is an interesting article, but the practical examples are all very hacky and make huge assumptions about the behavior of devices.

    What really stuck in my mind is “JAWS does not read the title of span elements” – now don’t you mean “JAWS, in the version I’m using and the configuration I have, does not read the title of span elements”.  JAWS has a multitude of options for controlling the verbosity of its output, when titles are read or not read, and how much meta-information is given.

    Likewise, the trick of using an anchor inside an abbreviation that JAWS doesn’t see as a link – I don’t know if any of its options could affect that behavior, but even if it’s solid, it seems to me rather arbitrary – there’s no good reason why it should do this, it just happens to do this.

    And what about other screenreaders? Earlier versions of JAWS, Windows Eyes, Hal or Connect Outloud?

    There’s an important proviso that this article overlooks, which is that users themselves must be prepared to take some responsibility, and in this case “users” means browser vendors as much as individual end users – the fact that IE doesn’t support <abbr> is IE’s problem; if individual users find themselves inconvenienced by this, they have technology choices; if JAWS users want to hear title text, they have the option to turn it on.

    Copy & paste the code below to embed this comment.
  27. It is clear to me that an acronym and an abbreviation are two different things. Yes, they are similar, but to me they are different enough that both the ABBR and ACRONYM tags should be preserved. I believe the article said something to the effect of “The days of surrounding abbreviations with acronym tags are numbered.” Well, I, for one, have never surrounded an abbreviation with an ACRONYM tag and just because maybe some people have doesn’t mean the ACRONYM tag should be deprecated.
    That brings me to another point. I know that within an XHTML document that tag and attribute names should be in lowercase but in articles such as this one I feel it actually helps to display them in uppercase. However, it seems like everybody feels they are going to violate some unwritten XHTML protocol by displaying a tag name in uppercase even when outside of an XHTML document. This always rubbed me the wrong way but I never said anything until I read this article and realized how much it would’ve helped for mentions of tags within paragraphs of text (not within actual sample snippets of code) to be in uppercase. So it is okay to write:

    <abbr href=”?glossary.htm#css”? title=”?Cascading Style Sheets”?>css</abbr>


    They say they are getting rid of the acronym tag and keeping the abbr tag for reasons unclear to most people.

    should be:

    They say they are getting rid of the ACRONYM tag and keeping the ABBR tag.

    I can’t go back and look at the article now without opening a new tab and hunting it down again and I think I remember that instances of tag names may have appeared in a slightly different font but even if that was the case it wasn’t different enough . . . at least for me.
    By the way, I honestly did not know what JAWS was while reading this article (although it slowly began to dawn on me through context clues) and a tool tip would’ve helped. I’m not bragging here but I am only semi-geeky. Geeky enough to know exactly what XHTML stands for though.

    Copy & paste the code below to embed this comment.
  28. Re: imagine hearing the sentence “We invite our readers to join us for our Wisc. area potluck”? without the abbreviation expanded

    This is an interesting example, because the difficult word for many people will not be “Wisc.” (Wisconsin) as the author apparantly thinks, but “potluck”. Potluck is a shared meal where the guests bring the food – similar to “potlatch”.

    Assume this example is real. When you’ve decoded “potluck”, the social factors are a much bigger problem. How do you decide which dish to bring, whether you should cook something or buy take-away, how much to spend, will some foods cause offense? Nightmare!

    My point it that, if you try to explain everything that will not be obvious to everyone, this is not just a matter of expanding abbreviations. You need footnotes, references to an Encyclopedia, and probably a contact address for advice. You will certainly end up doing a lot of work and may still not satisfy everyone.

    Copy & paste the code below to embed this comment.
  29. I agree with Mike Stone in comment #19.

    Accessibility is wonderful and thoughtful and often delightful, but accessibility for one group can be inaccessiblity for another group. The audience is indeed key.

    That said, the article was quite informative and useful.

    Copy & paste the code below to embed this comment.
  30. I was just reviewing the article whilst coding a page for a new site, and I came across with a link formed by the next piece of text *F1 Grand Prix*.

    I was trying out the proposed glossary technique for expanding the words “Formula 1” and noticed I was nesting an ANCHOR tag inside another one!

    Any comments on this issue?

    Aside from that, I found the article very useful and thought-provoking, as others have said.

    Copy & paste the code below to embed this comment.
  31. Earlier today I was looking at a page I was updating to add acronyms (I do not believe in getting rid of them because the current working draft is leaning against it, once it gets closer to/is ratified I may change my stance) and abbreviations and I found that my global search and replace caught an acronym within the alt text of an image. Must I expand the text in this case? How should one handle this?

    Copy & paste the code below to embed this comment.
  32. In XHTML 1.0 nested anchors are illegal: “a must not contain other a elements.”

    As for alt text abbr. depends on the audience and whether it occurs in the webpage. Though typically it would be deemed sensible to use the expanded form or parenthesis under most circumstances. Again the title attribute will come into play, if the image is meaningful enough.

    Copy & paste the code below to embed this comment.
  33. In XHTML 1.0 nested anchors are illegal: “a must not contain other a elements.”?

    I know, that is what I was asking: The article suggests inserting a link to the glossary page as well as the ABBR tag, but what happens if we have an abbreviation that is already inside a link?

    Copy & paste the code below to embed this comment.
  34. After reading your article and found following text segemnts

    - Our first goal is compliance with XHTML 2.0
    – IE 7 will support the abbr element;

    i ask me, is this article for the future or is this article really a suggestion for good web sites?

    Please note that XHTML 2 does not exist as a specification and IE 7.0 doesn’t work with the abbr element. It don’t know which Version of IE 7.0 you use, but the Version which is shipped with Windows Vista Beta 1 ignore the abbr Element.

    Next, i tested IE 7.0 with XHTML 1.1 and the Recommendation of W3C to serve XHTML 1.1 as “application/xhtml+xml”. IE 6 can’t work with this. And IE 7.0? He open it as a simple text document like open an XML document without DTD.
    So i ask me XHTML 2.0 and IE 7.0 are really good samples?
    Aside from that, your article is really good.

    Copy & paste the code below to embed this comment.
    1. I do not understand the article’s fuss about XHTML 2. It will last years until that specification is final, and it will last even more years until most browsers will get it right. And then there will still be various Internet Explorers around and we cannot use XHTML 2 with them. As it is not backwards compatible, we are forced to send HTML to the browsers. XHTML 2 is a technology for the back end.

    (Actual browsers don’t get HTML 4 or CSS 2 right. Those specifications are from last century, eight years old! And instead of fixing bugs and implementing complete and correct support for HTML 4.01 and CSS 2.0 [or CSS 2.01 at least] and preparing for CSS 3, browser vendors are making up new gimmicks for “HTML 5”?. But I am digressing ”¦)

    1. Instead of a class=“gloss” for the links, one could use the more semantic rel=“glossary” (known from the LINK element, also allowed for the A element). But, of course, Internet Explorer does not know about attribute selectors, so you will not be able to style rel-links and have to stick to classes.
    Copy & paste the code below to embed this comment.
  35. This article is almost screaming for PHP or similar language. With PHP one could define a list of words (abbr-list) with all the CSS code one could wish for, have a script run through each page and replace every occurence of any abbreviation in the abbr-list with proper coding. This way, you wouldn’t have to type every code out. And it would be easy to update which CSS code you want to put in the document as the misc. standards evolve.

    You could with minimal extra work have PHP serve different abbr-lists depending on what browser the reader is using to get the best of all worlds.

    Copy & paste the code below to embed this comment.
  36. I’ve been searching for an <abbr> solution that would work with IE6, and this is it!  ‘Nuff said!

    Copy & paste the code below to embed this comment.
  37. “Using Javascript to expand abbreviations.”:
    Two different solutions actually:
    – one script removes the TITLE attribute from the ABBR element, then the expansion of the abbreviation is done in plain text followed by the ABBR inside parentheses. Further occurrences of that abbreviation are left untouched.
    – the second script creates a glossary on-the-fly; it parses the document to build a collection of ABBR and TITLE values then creates a Heading and a Definition List containing all the element/value pairs.


    Copy & paste the code below to embed this comment.
  38. i thought this was a great article and if you need quality online casino, bingo or poker reviews take a look at

    Copy & paste the code below to embed this comment.