The abbr element

by .

The <abbr> element is not new to HTML5, nor has it been redefined. The HTML5 spec has, however, removed the <acronym> element, which was (and is) common in HTML 4 web pages. Simply put, instead of using <acronym>, use <abbr>.

What the spec says

The abbr element represents an abbreviation or acronym…

Straightforward enough, right?

How to use it

<abbr> is an inline element, so we can use it like this:

<p><abbr title="HyperText Markup Language">HTML</abbr> is the best thing since sliced web.</p>

Since it’s an inline element itself, <abbr> can be used inside other inline elements, like <strong> or <a>:

<p>The <a href="http://w3.org"><abbr title="World Wide Web Consortium">W3C</abbr></a> should hire the <abbr>HTML</abbr>5 doctors.</p>

Keep in mind that abbreviations aren’t always a series of uppercase letters. You can also use <abbr> to mark up a shortened word. For example:

<h1><abbr title="HyperText Markup Language">HTML</abbr>5 Doctors <abbr title="Incorporated">Inc.</abbr></h1>

The title attribute creates a tooltip for the user when they hover their cursor over the element:

abbr element tooltip example
Tooltip displayed to the user when hovering over an <abbr> element

The dotted border/underline is shown by default in Firefox and Opera, but IE8, Safari, and Chrome need a line of CSS:

<style>
abbr {border-bottom: 1px dotted black;}
</style>

The spec gives an example of how to use <abbr title="..."> if the abbreviation is pluralised. If the plural is inside the <abbr> element, then it should also be included in the title attribute. (This presumably applies to possessives as well.)

<p>What am I supposed to do with all these Beatles <abbr title="compact discs">CDs</abbr> now that I've repurchased them on iTunes?</p>
<p>I've packed in my job to become an astronaut on <abbr title="National Aeronautics and Space Administration's">NASA's</abbr> new space rocket!</p>

Acronyms and abbreviations: what’s the difference?

Although very similar, there is a slight difference between an acronym and an abbreviation. An acronym is a set of letters that forms a new word, such as NATO, while an abbreviation, such as BBC, does not, since you say each letter separately.

So why one over the other?

While there are subtle, pedantic differences between acronyms and abbreviations, the real reason HTML 4 defines two separate elements is simple: browser wars! Over a decade ago, Netscape created the <abbr> element while Microsoft created the <acronym> element. The W3C couldn’t (or wouldn’t) favour one over the other, so both have been in use ever since (until HTML5).

There’s always been a lot of confusion over these two elements and their usage. Witness it in this archive letter from 1997.

We also have browser compatibility issues with the <abbr> element. IE6 and IE7 do not support <abbr>, so many web developers have always used <acronym>. I know I certainly did when I worked for a big public-sector organisation — it seemed like every page had a dozen acronyms!

To get <abbr> working in IE6 and IE7, you need to create the element with JavaScript:

<!--[if lte IE 7]>
<script type="text/javascript">document.createElement('abbr');</script>
<![endif]-->

Conclusion

Thanks to confusion about their definitions and inconsistent browser support, <acronym> was dropped from both XHTML2 (now defunct) and HTML5. It’s been merged with <abbr>, which explicitly states “The abbr element represents an abbreviation or acronym”.

Hopefully you will find using <abbr> relatively straightforward. If you’re ever tempted to use an <acronym>, just use <abbr> instead!

29 Responses on the article “The abbr element”

  • Kroc Camen says:

    GARGH!! Noooo.

    `HTML` is a definition not an abbreviation.

    For love of markup, please read my article on abbreviations, citations and definitions. I‘ve been fighting against this nonsense use of abbr to define initialisms. http://camendesign.com/abbr_redux

  • David says:

    @Kroc Camen

    While I don’t disagree with your arguments about the use of <abbr> or <dfn>, I do feel both the author, his audience, and yourself are not better served by the tact taken when leaving your comment. As you yourself admit on the link you provided, you are not a grammar expert and that the guidelines you outline are born out of your own personal experiences and explorations of those elements (as your understanding has increased).

    It is, then, disingenuous to leave a comment such as the one above that reads with such authoritarianism and condescension.

    Of course, I say that in the scope that everyone is entitled to their opinion, and are as free to express it in any way they see fit as I am. I just can’t help but feel that your arguments and supporting assertions are less credible due to your less than tactful delivery.

  • Kroc Camen says:

    Okay, let me say it like this. Who does this article actually help? I tried for several years marking up every acronym / initialism with its full description, and all it did was create a massive amount of anal-retentive work that didn’t serve any solid purpose. If you actually followed the advice of this article, you would eventually go mad. It’s writing, for writing’s sake, rather than trying to nail down a practical, meaningful, semantic reasoning for using abbreviations and definitions (which are not even mentioned here!!).

    Sorry, HTML5Doctor, but you should already know that I speak my mind freely and only mean the best out of it, but this article helps nobody and teaches 10 year old practices that are and continue to be worthless to web authors and users. I’m pointing you to my article because _I gave a damn_ and thought through the semantics and practical value of this markup rather than regurgitating the spec.

  • Hi Kroc. Thanks for linking to your article, some good points there. I particularly like your examples of “!-” and “TCO”.

    It’s a good argument about when to use (or previously ). Hopefully this article and your article will help web authors.

    The examples above are valid use of the element but you think that is not always necessary and worthwhile. Maybe some readers who use, or have experience of screen readers can let us know their thoughts.

    TL

  • Let’s get some semantics straight, shall we? There is no difference between an acronym and an abbreviation other than an acronym is a specific kind of abbreviation: one that forms a word with the initial letters of other words, as stated in the article. BBC is a specific form of abbreviation called initialism: an abbreviation consisting of initial letters pronounced separately.

    NATO and BBC (both examples from the article) are both technically abbreviations, so the <abbr> tag is semantically sound by its official definition.

  • Artur Ortega says:

    Hi!

    I’m a screen reader user. Screen reader are able to define a different behaviour for each element , acronym and abbr, seperatley.

    I personally, as a lot of other blind users, let the screen reader read the expanded text for <abbr/> and let the screen reader read the acronym for <acronym/>.

    Here examples for <abbr/>: “e.g.”, “etc.”, “BTW”, “FYI”,

    Examples for <acronym/>: NATO, BBC, IBM, …

    I think you get the point, both groups are read differently. You would read always the expanded version of the first group, and you would always read the acronym of the second group.

    Screen readers are able to “smart read” the second group, NATO as a word and BBC spelled. The only thing the screen reader doesn’t know, when to read the expanded vesion and when to read the acronym.

    Therefore the differentiation in HTML4 was very important and the screen reader offered the possibility to distinguish the behaviour between gropu 1 (abbr) and group 2 (acronym).

    If we now get rid of <abbr/> in HTML5 we don’t have the possibility anymore to distinguish semantically the necessary different reading behaviour.
    this is unfortunately a huge step back in accessibility from html4 to html5.

  • Luke says:

    The grammar nazi in me wanted to share something.

    There are initialism, acronyms and abbreviations – all do essentially the same thing (reduce a long word, or collection of words into a shorter word), but the definitions of each are slightly different.

    An initialism is where a group of words are reduced to the first letter (or in some cases, first few letters), and those letters are placed one beside the other, in the same order as the words initially occured. So “BBC”, “CNN”, “FBI” are initialisms.

    An acronym is similar to an initialisation, however, the resulting string of characters is able to be pronounced to produce a new word. “SCUBA”, “NASDAQ” and “FUBAR” are acronyms.

    An abbreviation is where some characters from a word are removed, to produce a condensed form still recognisable as meaning the same as the original word. So “Dr” (Doctor), “Mr” (Mister), “Mrs” (Missus), “etc” (Etcetera) are abbreviations.

  • Florent V. says:

    One reason to do away with the acronym element is that, as Cameron pointed out, an acronym is a special kind of abbreviation. Abbreviation is a more generic name, and HTML tends to favor generic elements with its limited semantics. (Also, it happens that the English “acronym” is not the same thing as the French “acronym” and perhaps some other European derivatives.)

    Kroc Camen’s article was a great read (even though the comment’s tone and the very start of the linked article didn’t make a good impression). I like the invitation to not drown our text in semantic elements such as abbr just for the sake of it (bloat), and when we don’t really understand what that element means (risk of errors) or how it’s used by user agents.

    I would say the weakest point with this article and Kroc Camen’s article is that there is very little focus (or research) on User Agent implementations. Kroc advises to use abbr with no title attribute to tell user agents (especially screen readers) that the text should be read as a word and not as separate letters, and to use abbr plus the title attribute to give the spoken form of some abbreviations. That second use case seems sensible regardless of the efficiency of implementations (or lack thereof). The first one, on the other hand, is not really supported by HTML4 and HTML5 specification text, and only makes sense if user agent implementations are consistent with this advice. Also, what about CSS 2.1 aural styles, do they help?

  • @Artur — part of the reason for dropping <acronym> in favour of just one element was the instances of correct usage were so low, mainly due to IE’s lack of support for <abbr>. Because of this, I’m wondering how often you encounter any of your “read the expanded text for <abbr>” examples. In your experience do the instances of <abbr> with a useful title outnumber incorrect usages?

    Also, I personally wouldn’t choose your division into expanded and unexpanded versions — for example, I wouldn’t want FYI expanded (probably because I’m the sad type that would actually say “F.Y.I.” in conversation ;). Conversely, there are also many acronyms that I would want to know the expanded version of (anything I’m unfamiliar with). I’d love it if you could tell us more about this.

    @Kroc — “`HTML` is a definition not an abbreviation.” — this is not true. “The dfn element represents the defining instance of a term.” HTML is by definition an abbreviation (rimshot! sorry :), although you could choose to mark up the first instance with <dfn> in addition to <abbr>.

    Re: your sanity, there’s no requirement to use <abbr> — it’s something that should you use it increases the content’s usability (ref: Artur’s comment). As with everything it’s a sliding scale. Since marking these up by hand is indeed repetitive, consider automating it, and as Tom mentions only marking up things your audience will be unfamiliar with. Unfortunately the CMS plugins that do this haven’t been updated for an HTML5 world, however here are some links from back in the day to get you started:

  • Artur Ortega says:

    For being able to specify if a word is to be read (normal/spell-out) you can use AAural CSS: http://www.w3.org/TR/CSS2/aural.html
    At the moment there aren’t a lot of screen readers making use of this CSS property but this would be the right semantic way to do it.

    IMHO leaving out the title attribute isn’t the right way to deal with different kind of pronounciation.

    ABBR and ACRONYM were supported in IE when using JAWS. You probably didn’t see any tool-tip but you were able to distinguish between reading the expanded or non-expanded word.

    I don’t find any semantic way to provide this reading differentiation semantically in HTML5 without making any WAI-ARIA gymnastics.

    Any ideas?

  • Johan says:

    While I agree with Kroc that this article could be extended with more information, I don’t agree with it being a useless post. At the very least, I now know WHY abbr is prefered over acronym, in the specification, anyway.

    I also agree that there should be more research in what UA actualy DO with both tags. I think I might give a shot at that once i sorted my own site out.

  • @Oli: You’ve misunderstood Kroc. His point is that marking up HTML as <abbr title="Hypertext Markup Language">HTML</abbr> is defining HTML. It is an impractical and useless way to markup the abbreviation because no one ever says the expanded version. When was the last time you said anything other than “NASA” either? Such practice is to confuse the distinction between <abbr> and <dfn>

    Even using <abbr> (without title) to markup any abbreviation is totally impractical. In my opinion, Kroc’s article is valuable in helping to remind us that we need a practical and consistent solution if the use of these elements is to mean anything, be sensible and practical, and be taken up by anyone other than those with OCD.

  • Jeremy Keith says:

    Kroc, I read your article. It is incorrect. You have decided that dfn means “definition.” It doesn’t. It means “defining instance.” With that clarification in place, your article (and your aversion to the abbr element) no longer holds water.

  • @Artur — I’m still wondering what reading distinction you’d like to have, as for me the list of abbreviations to be expanded/replaced with their @title and the list of abbreviations to be read out would seem to depend a lot on the person listening. That would require some function in the screen reader to determine which is which, and isn’t something that an author could do.

    I’d also still love to hear if you encounter words you wish to have replaced with title marked up with <abbr>, and those you wish to be read as-is marked up with <acronym>, more often than not. Even given my OCD I’ve never added <abbr> to any of the ‘expanded text’ examples you gave, so I wonder how often you encounter these in the wild.

    @Nicolas — Umm, no I haven’t. Follow those links in my comment for great justice ;)

  • To elaborate on what Jeremy said, according to the spec:

    The paragraph, description list group, or section that is the nearest ancestor of the dfn element must also contain the definition(s) for the term given by the dfn element.

    WHATWG specification

    You should explicitly define the term in the prose surrounding it in order to use <dfn> correctly. Also:

    If the dfn element has a title attribute, then the exact value of that attribute is the term being defined.

    WHATWG specification

    The title of the <dfn> does not contain the definition of the term. It (optionally) contains the term being defined.

  • Nicolas says:

    @Oli: True :). In fact, the HTML5 spec is pretty clear about when it’s most useful to use abbr…without expecting most abbreviations to be marked up with the element:

    Abbreviations do not have to be marked up using this element. It is expected to be useful in the following cases:

    * Abbreviations for which the author wants to give expansions, where using the abbr element with a title attribute is an alternative to including the expansion inline (e.g. in parentheses).

    * Abbreviations that are likely to be unfamiliar to the document’s readers, for which authors are encouraged to either mark up the abbreviation using a abbr element with a title attribute or include the expansion inline in the text the first time the abbreviation is used.

    * Abbreviations whose presence needs to be semantically annotated, e.g. so that they can be identified from a style sheet and given specific styles, for which the abbr element can be used without a title attribute.

    WHATWG specification

  • @Nicolas — Bah, the damn spec is far too informative! Where’s the semantic interpretation wiggle room!? Itellya, that Hixie is taking all the fun out of (arguing about) the web. Why in *my* day…

    ;)

  • David L says:

    I love it when Mr Camen has a rant… in a good way it got me reading the rest of the artical and comments. i think you should make it a feature of this blog 2p done

  • Gary Miller says:

    Good article and comments.

    It’s given me food for thought for an article of my own.

    Just one small, teensy weensy detail. When I was at school, the A in NATO stood for Atlantic and not American!

    Cheers!

  • @Gary Miller — thanks, fixed. Brandan will be embarrassed about letting that one through! :D

  • Peter says:

    [Comment removed. As you Mama said, if you can’t say anything nice… ;) —ed.]

  • Alice Wonder says:

    In response to Artur Ortega, is this a place where aria role attribute might help screen readers do the right thing?

    I am only beginning to learn about aria and I still have a ways to go, but for example,


    <abbr role="acronym">SCUBA</abbr>

    to let a screen reader know that it is an acronym and thus despite being spelled upper case, it should be read as a word?

    Can anyone familiar with aria and/or aural style sheets perhaps comment on this and suggest how it should properly be handled?

    I would really like to know.

    Thanks,

    Alice

  • Loved the article. Loved going through the comments even more… :-D

    Though the argument gets a bit pedantic at times, it’s a brilliant read. Especially for understanding the nuances of the English language…

    Thanks for putting this out there!

  • Edward says:

    @Nicolas Gallagher – I don’t think tagging abbreviations such as HTML is impractical and useless just because people do not read the text using the spelled out version.

    Consider this example, two documents both including the abbreviation CIA. However, one document is referring to the Central Intelligence Agency and the other is referring to the Culinary Institute of America (obviously different). When indexing these documents a search engine could improve its index accordingly, so that a search for “culinary” would return one document but not the other.

    I am bothered by the fact that abbr wil be used for purposes like the above and by screen readers. How and when to use abbr may conflict depending on your goal.

  • Kevin Rapley says:

    @Alice Wonder — ARIA doesn’t define a role of acronym, but I like how you are thinking with this. ARIA has a specific taxonomy which can be seen at http://www.w3.org/TR/wai-aria/rdf_model.

  • Paul Gowan says:

    The article does a decent job of clarification and the insightful comments have highlighted good points. While humans might never bother to say ” Light Amplified by the Stimulated Emission of Radiation”(LASER), Canadian Broadcasting Corporation (CBC), or United Nations Educational, Scientific and Cultural Organization (UNESCO) etc. after the first few encounters with the abbreviation/acronym/initialism, I want WATSON and other forms of artificial intelligence to be able to pick such words out of a document. Having just one tag available rather than two is helpful. Culinary Institute of America will have a unique title that distinguishes it from Cemtral Intelligence Agency. One could get into some off topic discussion about RDF, URIs and the semantic web at this point.
    The points about providing pronunciation and some type of hypertext defining imstance are good and I wonder what the official answers are. Use Javascript with title? How is it done on howjsay.com? (http://www.howjsay.com/index.php?word=nato&submit=Submit )
    It might seem like an OCD to use in every possible instance but might help machine readers. It’s just very inconvenient for human website designers. E.g. in contact information with Dr., Mr., Mrs.,Rev., Sen., Ph.D., Apt., 1st, 2nd, 3rd, 4th, etc., NE, SE, NW, SW, N, S, E, W, etc., Ave., Blvd., St., Rd., etc., 2 letter U.S. state, 2 letter Canadian province, 3 letter country designation etc.
    Would it be better to have an online ( E.g. Open Calais, Open CYC) or offline ontology and parser for those words?

  • Here’s a small suggestion that has absolutely nothing to do with semantics:

    For your border-bottom-enabling css, leave out the color in order to making the border inherit its color from the text (which is what automatically happens in Firefox by default). Red text will then have a red dotted underline, instead of a black one.

    So rather use this instead of what the article suggests:

    <style>
    abbr {border-bottom: 1px dotted;}
    </style>

  • Ian Yang says:

    Although it’s convenient for coders to just include the title attribute on the first use of an abbreviation and omit it on subsequent uses, I sometimes worry about circumstances in which visitors arrive on a page and jump to a section directly through a hyperlink with hash (which causes the jump).

    In such cases, if “the first use of an abbreviation” is in an above section, visitors won’t see a tooltip when mouseover the same abbreviation in the current section.

  • Paul says:

    Speaking as someone in the process of converting a large site from xhtml to html5… AAARGHHH

    The joys of replacing every instance of an acronym with abbr because Microsoft didn’t want to play ball with the rest of the industry, now all of a sudden, abbr is the way to go?

  • Join the discussion.

    Some HTML is ok

    You can use these tags:
    <a href="" title="">
    <abbr title="">
    <b>
    <blockquote cite="">
    <cite>
    <del datetime="">
    <em>
    <i>
    <q cite="">
    <strong>

    You can also use <code>, and remember to use &lt; and &gt; for brackets.