Explaining abbreviations, acronyms and symbols on Web pages

There is some markup in HTML that could be used for abbreviations and acronyms. However, such markup should not be regarded as a replacement for explicit explanations in normal document content. In fact, using abbr or acronym markup is mostly useless if not worse. The real need is to explain to users all notations that might otherwise be unknown to them or have meanings that differ from their expectations. We discuss here how the explanations should be given so that users can benefit from them but do not get distracted by them when they are irrelevant.

• Introduction: the accessibility guidelines
• The markup: abbr, acronym, and span
• Presentational details
• Explain the notations
• Proposed guidelines

Introduction: the accessibility guidelines

The Web Content Accessibility Guidelines (also known as WAI guidelines) say:

4.2 Specify the expansion of each abbreviation or acronym in a document where it first occurs. [Priority 3]

For example, in HTML, use the "title" attribute of the ABBR and ACRONYM elements. Providing the expansion in the main body of the document also helps document usability.

Techniques for checkpoint 4.2

This might be read so that the markup elements are presented just as tools that could be used along with other methods. But it seems to be a common interpretation that they are an accurate description of what you should do when authoring in HTML. The techniques document that the above text indirectly refers to, part Acronyms and abbreviations of the document discussing HTML techniques for accessibility guidelines, seems to confirm this idea. I think the idea is all wrong: the markup discussed there might be a nice extra, but it's neither necessary nor sufficient for implementing what's really needed. It's the explanation in the main text that is the real thing; whether a mere expansion is sufficient there depends on the context and expression.

Apparently the idea behind the checkpoint revolves around a "tooltip" implementation for title, though of course no specific implementation is required. Some browsers show the value of a title attribute in a small popup window when the cursor is moved over an element with such an attribute. They might, or might not, use e.g. a dotted line below the element text to give a hint of the availability of a tooltip.

Although the "tooltip" behavior is common in modern graphic browsers, it is not suitable to rely on it, especially from the accessibility perspective. Some speech-based browsers may give the user optional access to title attribute values, but they tend to ignore them by default. Moreover, people using a graphic browser without a mouse, or with serious difficulties in using a mouse due to a motoric disability probably cannot invoke the "tooltips".

Perhaps due to some realism, the checkpoint says that only the first occurrence of an acronym or abbreviation should have an attached expansion. But then the usefulness of the markup is greatly reduced, since browsers don't seem to keep record of the acronyms and abbreviations so that the tooltips would be available upon each occurrence. A mere expansion usually doesn't tell very much, but it might be a useful reminder, if it were available whenever the abbreviation occurs.

The approach in the checkpoint is disturbingly technical. Surely there are many other notations than just abbreviations and acronyms that need to be explained. Besides, the markup mentioned is far from universally supported in the sense that the user would have access to the explanation provided in the attribute. It's questionable whether we should ever consider such markup as providing anything but optional explanations, as "nice to know" information. After all, the title attribute is defined as specifying an "advisory title".

It might be nice to know what the acronym "radar" comes from; but it is pointless to require that any document using that word must give the expansion for the acronym. On the other hand, when you use for some essential purpose an abbreviation or technical term that is not generally known, it would be crucial to explain it, or provide a link to a definition. Little does it matter whether it's an abbreviation or a word or special symbol.

See also ABBR and ACRONYM are for user agents not for end users by Jesper Tverskov.

The markup: abbr, acronym, and span

In principle, abbr means abbreviation, acronym means acronym, but there is no understandable description of the difference in the HTML specification or other specifications.

I think the real reason behind the confusion is that one browser vendor invented abbr and another vendor invented acronym, for essentially the same purpose. They couldn't agree on it, and the W3C didn't want to decide on it, so both elements were taken into HTML 4.0. Yet, Internet Explorer version 6 still doesn't support abbr. (IE 7 beta preview seems to recognize it and to support the "tooltip" behavior for it.)

Many people think that "acronym" means what general dictionaries say about it: a word formed from some initial letters of an expression. Thus, it should be a pronounceable word, not just any initialism. But others have said that the world "acronym" is commonly used for all kinds of initialisms, such as "TLA"; these people often say that "abbreviation", on the other hand, would only mean abbreviated forms of words, such as "Inc." for "incorporated". At the extreme, one might count an expression as an abbreviation only if it is always to be read as expanded; that is, if it is actually just a contracted written form of a word or sequence of words.

An abbreviation is generally something formed from an expression by omitting letters. This may involve changing the case of the remaining letters or adding a period to indicate an abbrevation. But basically, you take some words and omit some letters or, to put in other words, pick up some letters and use them together to stand for the full expression. Logically, then, it follows that in English expressions such as "i.e." or "lb" are not abbreviations in English.

It is natural to regard an acronym as a special case of an abbreviation. But not all people agree with this, as mentioned.

For a futher discussion of abbr versus acronym, consult the document HTML is not an acronym at evolt.org.

What about expressions like "cm" for centimeter? In some sense, they are abbreviations by their origin. But the standard for the international system of units makes it clear that things like "cm" are identifiers that are to be used as such in all languages. In Finnish, the word for centimeter is "senttimetri", with no letter "c" in the spelling, so you can't say that "cm" would be an abbreviation of that word. Still less is "cm" an abbreviation of the verbal expression for centimeter in Chinese.

There's little you can do to please everyone. And there's always the possibility that some people create software that processes HTML documents according to some particular interpretation of what "abbreviation" and "acronym" mean. For example, according to one interpretation, it would be quite natural for a speech generator to try to pronounce the content of any acronym element as a word. On the other hand, some wordings in some specifications suggest that someone might get the idea of reading, in automatic speech generation, abbr elements (and perhaps an acronym elements too) as expanded to the full expression you have given in title attributes. Let's hope this won't happen.

1. If you use acronym, use it only for pronounceable words formed by abbreviating an expression, e.g. <acronym title="Disk Operating System">DOS</acronym>
2. If you use abbr, use it only for expressions that are abbreviated forms of expressions in the language where they are used, e.g. <abbr title="Federal Bureau of Investigation">FBI</abbr>
3. Otherwise, if you wish to associate an advisory title with some piece of text, use the span markup, unless it's already enclosed in some markup for some reason. The span markup is semantically empty, so at least it does not give wrong information about the structural nature of its content. Examples: <span title="centimeter">cm</span>, <span title="pound">lb</span>, <span title="Sigma">&Sigma</span>.
4. Don't take pressures to use such markup for all abbreviations, acronyms, and notations. There are more essential things to do.

Presentational details

Some browsers use a dotted line below the text of acronym and abbr elements, at least if they have title attributes. Technically, it's actually a dotted bottom border, in CSS terms. That is, it is affected by border properties, not by text-decoration properties.

The dotted lines below acronym and abbr elements might be of the same color. So maybe you'd like to distinguish them from each other, e.g. so that for abbreviations, the color is blue and for acronyms grey.

If an abbreviation is accompanied with its expansion in the text, it's probably unnecessary to use abbr markup. The same applies to abbreviations which are either generally known, as "Mr." in English, or can be assumed to be known to the target audience. But should you wish to use it, perhaps expecting some programs to extract abbreviations and their expansions automatically from documents, you could use CSS to suggest that the dotted line be omitted. After all, it could create false expectations about additional information being available. You could use markup like
Environmental Protection Agency (<abbr title="Environmental Protection Agency" class="redund">EPA</abbr>)
in conjunction with a suitable style sheet.

In printed documents, the dotted line is probably just confusing. You might thus want to use a style sheet that suppresses it for print media.

abbr    { border-color: #00f; }
acronym { border-color: #222; }
abbr.redund, acronym.redund { border: none; }
@media print {
  abbr, acronym { border: none; } }

Safari, an advanced browser for the Mac environment, has some odd features, including the feature that abbr and acronym elements appear in italics be default. (This has been reported in the document Safari Surprises.) This is very confusing, since italics is the default rendering for quite a few elements in HTML and can easily be understood as some kind of emphasis. To protect against the feature, you could use the following style sheet:

The sample style sheet for HTML 4.0 in the CSS specification contains the rule
ABBR, ACRONYM { font-variant: small-caps; letter-spacing: 0.1em }
but this does not correspond to actual browser behavior. And those features would be rather unsuitable for many, or most, abbreviations and acronyms, such as "tel.", " TCP/IP", and "radar". (You might see these examples as rendered according to the rule mentioned above. Since IE 6 does not recognize the abbr markup, I have cheated a little by using additional span markup.)

Explain the notations

The simple rule is: Use words and other expressions that are familiar to readers. If you need to use other expressions, such as abbreviations for brevity or technical terms for accuracy, explain them before their first use. Preferably, put the explanations somewhere as a handy list for reference, too. You might combine these so that the explanation in the text contains a link to the reference list, which may then contain a longer explanation and further references.

A list of explanations, or a glossary, is particularly useful when the material will probably be used in a hypertextual manner, so that there is no strict linear order, hence no strict "before" relation. The glossary might appear at the end of a document or, especially if the material is divided into separate pages (HTML documents), on a page of its own. Naturally, you would refer to the glossary with links often enough so that the reader is likely to find it if needed.

Especially for abbreviations used basically as terms, the expansion of an abbreviation is generally not sufficient for telling what it means. Quite often the expansion is obscure, ambiguous, or too generic. The expansion "File Transfer Protocol" doesn't really tell what "FTP" means. The expression "FTP" is actually the name for a particular protocol, not for any file transfer protocol. Consider the expansion just as something that helps to remember what the abbreviation means.

Technical terms and unusual words need to explained, just as unusual abbreviations need explanations. This especially applies to terms that have different meanings in different areas of life. For example, "ichthyology" is not a very common word, but it has a single meaning, which can be found by consulting a dictionary. The word "induction", on the other hand, despite sounding more familiar, could be in greated need for an explanation, since it has so many different meanings, as a term of physics, or biology, or logic, or something else.

The practicalities depend on the nature of the material, the length of an explanation required, and the assumed prior knowledge of the readers. It is frustrating to read explanations of something that you know very well, even regarding it as trivial. But it is even more frustrating to find yourself in the middle of abbreviations and terms that you have no idea of.

Proposed guidelines

In these guidelines, the word "term" refers to any expression that needs an explanation, whether a technical term, an abbreviation, a special symbol, an uncommon word, or something else.

• At the beginning of your document or the main page of a collection of documents, try to indicate what previous knowledge is assumed and to refer to a suitable dictionary or other reference material. Ideally, you would link to a single online reference for most of the terms you use, and you would explain in detail all the terms that are not present in it.
• Based on the above-mentioned assumption, explain each term when it is first used, if the term falls outside the assumed knowledge. If in doubt, include it.
• Short abbreviations often need explanations even if they are widely known, since they may have different meanings in different areas and to different people.
• If the expansion is a sufficient explanation of the meaning of an abbreviation, you can write first the full term, then the abbreviation. Example: "Environmental Protection Agency (EPA)". You could alternatively do the other way around, putting the expansion in parentheses after the abbreviation. This would be natural when the abbreviation is in fact more widely known than the expansion, as in "CIA (Central Intelligence Agency)".
• If there are more than, say, a dozen terms, include a glossary, too. It should contain the definitions formulated so that they are understandable in any context, so they might be worded differently from the definitions in the text.
• If there is a large number of terms that are presumably well-known to many readers but unknown to many, consider some special convention. You could put their definitions into the glossary and link to them upon first occurrence. The links might carry some special sign or presentational feature to distinguish them from normal links to external documents. Naturally such a convention, like putting an asterisk in front of the term occurrence, would need to be explained in the beginning of the document.
• It doesn't hurt to use the markup discussed above, as an additional comfort to some users. For example, for terms that have definitions in a glossary only, the title attribute could be used, letting users check quickly whether they understand correctly what the term means. However, in practice this would mean that the attribute is attached to the link element (a href) This could be something like the following:
  You can use <a href="gloss.html#ftp" title= "File Transport Protocol - a method for...">FTP</a> to...
  (Here the ellipsis is a hint suggesting that the link refers to an explanation that contains more than just the expansion.)
• If some term occurs in different places in the document, so that the reader may easily have forgotten the definition, consider linking to a definition (in text or preferably in a glossary) from each occurrence. Here, too, some notational convention, if explained, may help users in distinguishing such "reminder links" from other links.
• If you lack resources for writing definitions and glossaries, linking to external documents that explain your terms is mostly more useful than leaving readers in the dark. However, the linked resources should be reasonably reliable and stable. It's better to let readers use search engines than to offer them links to useless, or worse than useless, reference material.