Dealing with Acronyms & Abbreviations

Posted February 19th, 2007 by Mike Cherim

For quite some time the methodologies of how best to deal with acronyms and abbreviations on the web have been discussed by developers the world over. We seek the best practices and hope to serve all of our visitors with something of use. But what is the best way? How do we please all of the people all of the time? Is it even possible? Let’s explore this further.

First, What’s the Difference?

An acronym is an abbreviation — it’s a special instance of an abbreviation. How it is handled verbally makes it unique. The best way to tell the two apart is not the use of initial letters — abbreviations can be either — but rather on how the instance is spoken. The dictionary will state acronyms are composed of initials, but I find this isn’t always the case.

An example of an abbreviation would be HTML, short for “HyperText Markup Language” and it is spelled out when verbalized: H.T.M.L. Conversely, DOM, for “Document Object Model,” is an acronym because it is spoken when verbalized: DOM. Some are acceptable either way, such as PNG, for Portable Network Graphic, which is sometimes spoken as “ping”). When in doubt, use the abbreviation element.

Making Them Accessible

Using the rule-of-thumb above, marking-up instances becomes simplified. The tricky part is how to do this so users can derive meaning when and if needed. Essentially they may want or need three things when they encounter an abbreviation or acronym on a web page:

  1. To know how to vocalize the instance.
  2. To know what the letters stand for.
  3. To understand the meaning.

These will become our goals as developers; to meet these basic needs while not overloading the user with senseless information, page clutter, and extraneous mark-up. If all of this information is presented in a way that’s accessible and offers meaning then we will succeed — and so will our visitors. Let’s take a closer look on how we might achieve these goals.

Marking Them Up

There are two elements used for marking up acronyms and abbreviations: acronym and abbr, respectively. These are recognized by most browsers and valuable to a number of Assistive Technologies (AT), like screen readers and such. With one notable exception: Internet Explorer (IE) version 6 and earlier does a very poor job in the way of offering support of the abbreviation element. Visually, as you probably know, IE6 and older can process acronyms but fails with abbreviations. Fortunately, some screen readers using IE as a platform will process abbreviations anyway.

The answer to the IE visual support issue, for many developers, is to simply use the inappropriate element. Unfortunately, doing this means all abbreviations will not be offered for what they are — the element’s value will be lost. The audience would likely know better. And so would many ATs. But just because users and equipment can deal, doesn’t mean it’s the best way.

Ineffective Workarounds

There are methods used to skirt the issue: One is to use the proper element and apply a span around it or in it, and apply the title attribute to that. This addresses visual styling and interaction for IE users — which can help a lot of people. But if title attributes are expanded by the screen reader user, which isn’t typical anyway, they lose meaning if the title is applied to the span. Therefore the title attribute must be within the abbreviation element. Doing this, though, means IE only gets the styled span and no additional info. Do both and it will be redundant if titles are read.

Another method, which helps with the vocalization, is to add spaces — closed with a Cascading Style Sheet (CSS) entry — between the letters, or to use characters, such as periods, but this adds to the workload and doesn’t offer much else. There must be a cleaner and easier solution that offers more value. Something more natural. Especially for inline/in-text instances.

A Better Way?

After much discussion, we’ve decided the best possible solution might be to draw our methodology from the print word, but enhanced with web interactivity. What we propose is to expand the first occurrence in pure text form such as what we’ve done in this article. Here’s an example using an abbreviation linked to a glossary or footnote definition.

In the first instance of this abbreviation in this article it is expanded like so.

Assistive Technology (AT)

Not including the strong emphasis added to the example, here’s the mark-up used in this first instance:

 <!--First occurrence-->
 Assistive Technology (<a href="" title="Link to Glossary"><abbr>AT</abbr></a>)

Later instances can be simplified by providing just the parsed abbreviation with title attribute, like so:


Not including the strong emphasis added to the example, here’s the mark-up used in subsequent instances:

 <!--Secondary occurrences-->
 <abbr title="Assistive Technology">AT</abbr>

Since the abbreviation has already been expanded on the page as plain text and a resource given that will help solve all of the developer’s goals, we need to do nothing more. This includes styling to show a visual interactivity. In reality it simply isn’t needed. This doesn’t mean we won’t add some styles. We will. We’ll actually remove the default styling as it’s really not that helpful in light of the fact it’s been expanded already. At this point dotted underlines offer clutter and not much more.

 /* Default styling to avoid unnecessary visual clutter */
 abbr, acronym {
   border : 0;

Now Apply Common-Sense

Should all acronyms and abbreviations be marked up in this way? Probably not. We’ll drive ourselves crazy marking everything up. It’s probably best to let some abbreviations and acronyms be, avoiding those where supplying this mark-up would probably be unnecessary. An example is “radar” (which is actually a word now). Unless the site is explaining radar, knowing this is an acronym and what it stands for is unimportant. If it was a site explaining radar, it would be best written acronym-first on the first page instance, like this: Radar (RAdio Detection And Ranging) and it would either be linked to a glossary definition or simply explained within the text body. If the site was discussing radar itself, explaining it within the text would probably make the most sense. If the the site was explaining maritime and aeronautical technologies, use of a glossary might be best. In either case, marking up secondary occurrences would be gross overkill.

Much depends upon the ubiquity of the term. For example, the acronym WYSIWYG is pretty specific to an industry so it would be of some value to explain it by way of a glossary or footnote and apply the necessary mark-up. USA, on the other hand, should probably be added without any expansion. The general public knows what it means. It’s not specific to a particular sub-set of visitor. Of course if those letters have some not-so-obvious meaning this last part wouldn’t apply.

Multi-Page Articles

On the web it’s quite possible for a reader to access a multi-page article at some point other than its beginning. If this happens they may miss the first occurrence. Thus they’d miss the glossary/footnote link and text expansion. That said, it is reasonable to expect the reader to know that coming into the middle of an article might leave them in need of the explanation of terms and a general understanding of the context. To be safe, though, you may want to repeat first instance protocol on every new page. This is a tough call; you will want to do the right thing without too much redundancy, but you don’t want to leave anyone without basic understanding. I suppose it depends on what the acronym or abbreviation is, how it’s used, and who the expected readers will be.

Users that might have dyslexia may need repeated occurrences even if they do access the article from its beginning. The result may be too much verbosity for everyone else. You decide.

The Glossary or Footnote

On this site we try to meet the needs of our users by supplying a glossary of abbreviations and acronyms we will use repeatedly, and a footnote for seldom-used, article-specific terms. In both cases we use a definition list, dl, to mark-up these page structures.

In our glossary, if the instance is an abbreviation, we provide periods between the letters to indicate to visual users that the term should be spelled out and not spoken, and we provide a brief meaning. We also parse the instance with the appropriate element, but without the title attribute. We provide the same in the footnote.

If it’s an acronym, we drop the periods but offer a pronunciation, also followed by a brief definition. We feel this provides the necessary information to anyone who may want or need it.

In Closing

Could this be a “best practice” in your mind? This has been a tough subject to cover, especially since we don’t even know the full intention of the World Wide Web Consortium (W3C) and the whole subject seems to be shrouded in mystery. What are your thoughts?

Update: March 2007

I added a glossary link class called, class="gloss". The decoration is a color change, gray dotted border and help cursor change.

PNG, or Portable Network Graphic, is an image format sometimes used on the web. It can be identified by the file extension, i.e., image.png. It is said to be a lossless format. (Back to PNG Instance)

16 Responses to: “Dealing with Acronyms & Abbreviations”

  1. Arjan Eising responds:
    Posted: February 19th, 2007 at 1:03 pm

    Nice to see that all I know about this is correct :)

  2. Rich Pedley responds:
    Posted: February 19th, 2007 at 2:06 pm

    Nice article, even if I don’t agree fully with you. Though we are close to banning discussions on this topic at home, as we can never agree.

    In theory though you have missed several instances on the page, USA and i.e. I know what the first is, but can never ever remember what the second stands for!

    Pepper a document with abbreviations and acronyms and by using your method of linking to a glossary or a footnote you can suddenly find that the number of links per page has increased more than you had hoped. (not so much a problem here, as you don’t include a navigation menu on every page).

    I also found it amusing when I first hovered over PNG to find that it meant footnote - I expected the title to be the expanded version and it wasn’t. So maybe the title should be expanded to include why you are being sent somewhere else to find the meaning, like ‘link to footnote’ or ‘link to glossary’. Though ‘link to’ may not be the best phrase to use.

    If assistive technology was up to speed I would have expected them to be able to create a list of abbreviations marked up on the page. Am I correct in thinking they cannot currently do this?

  3. Elliott Cross responds:
    Posted: February 19th, 2007 at 2:26 pm

    Glad to see this idea and I will definately put it too use! I can see that this will be a huge benefit to pages, especially legal disclaimers, policies, etc. that are posted on the web for clients and customers. The problem I have run into while marking up a page is the age-old question of ‘Do I need to code all abbreviations or acronyms?’ Thanks for the great tip, and a Bigger thanks for all of the work to improve accessibility design and markup!

  4. Santiago UrueƱa Pascual responds:
    Posted: February 19th, 2007 at 4:39 pm

    Thanks for the article, there’s no a lot of info about the correct usage of those tags. However, I heard that the ‘acronym’ tag is discouraged and only the ‘abbr’ element should be used because the ‘acronym’ tag will be deprecated XHTML 2.0. Am I right? Best regards

  5. John Faulds responds:
    Posted: February 19th, 2007 at 9:45 pm

    Saw mention of this on the WSG mailing list today. Apparently, (according to Nick Fitzsimmons who gave a presentation about it at BarCamp in London), IEabbr with this:


  6. Rich Pedley responds:
    Posted: February 20th, 2007 at 4:19 am

    actually Mike since I posted that comment I realised that that title text won’t be sufficient either. (well to me at least). Would it be better as “Glossary definition for …” ?

  7. Benjamin Hawkes-Lewis responds:
    Posted: February 21st, 2007 at 4:31 am


    XHTML 2 is an early draft for a radically different markup language that is incompatible with HTML 401 and XHTML 1.x. Nothing in XHTML 2 changes the meaning of elements like ABBR and ACRONYM in other markup languages. If you’re using an acronym in HTML 4.01 or XHTML 1.x, you should use ACRONYM because that’s the right element for the job. In other words, mark up documents according to the specification you’re currently using, not hypotheticals about specifications you might be using for other documents in the future.

  8. Mel Pedley responds:
    Posted: February 21st, 2007 at 5:08 am

    Quoting Rich:

    In theory though you have missed several instances on the page, USA and i.e. I know what the first is, but can never ever remember what the second stands for!

    “i.e.” is Latin for “id est” - which translates to “that is”.

    Personally I’m in two minds as to whether I’d mark that up. Strictly speaking, it is an abbreviation but taking markup down to that level might just be taking things a little too far. If it was expanded (presumably including lang="la" as part of the abbr markup) , 99 out of 100 people wouldn’t have the faintest idea what the expansion meant, so you could end up just causing confusion.

  9. Colin Lieberman responds:
    Posted: February 26th, 2007 at 11:41 am

    Mike - I came to a very similar conclusion about a year ago, which I outlined in this article. I’m curious though why you do not attempt to convey to sighted users that they may hover over an abbreviation to get a definition. It seems unreasonable to me to hide information from users - sighted users won’t know there is information available unless you tell them (somehow), and I still feel that the standard dotted-underline is a great way to do this.

  10. Alison Ray responds:
    Posted: February 26th, 2007 at 11:52 am

    Hmmm, this is very similar to an article in A List Apart from a year ago…
    Some of the coding looks exactly the same…

  11. Stevie D responds:
    Posted: March 2nd, 2007 at 8:52 am

    Putting “link to glossary” as the anchor title is not sufficient on its own. It would be less effort to put the expansion of the abbreviation in the [abbr title=”…”] and in most cases this would be sufficient. Only when this doesn’t give enough explanation should a link to the glossary be considered, as it is on a separate page it will slow users down and break their reading flow considerably.

    Likewise, if you have a footnote reference, the title is the ideal place to replicate the footnote text. eg,

    In the main text, you have a reference [a href=”#note1″ title=”Text of footnote here” class=”footnote”]1[/a]

    and then at the end of the page, repeat the footnotes as you would in any normal document. This allows most people to read the footnote without interrupting the main flow of text.

    And as for not using elements because they are deprecated in XHTML2 - so what? IE6 is still a reality, and so (regrettably) we need to use code that it can cope with. XHTML2 is not here yet, and there’s no reason why you have to use it. You’ll have to revalidate all your pages if you do use X2 anyway, so it won’t hurt to change all your acronyms to abbrs then. From what I’ve seen so far, I’m more likely to switch to HTML5 than any form of XHTML next!

Sorry. Comments are closed.

Note: This is the end of the usable page. The image(s) below are preloaded for performance only.