Standards, BEST PRACTICE, accessibility, usability, XML
ABBR and ACRONYM are for user agents not for end users
The WCAG (1.0) guideline 4, checkpoint 4.2, about ABBR and ACRONYM, has for a long time been too unclear to implement. The drafts for XHTML 2.0 and WCAG 2.0 seem to have solved most problems.
- ACRONYM is dead and out
- ABBR and pronunciation
- Only use ABBR when not in dictionary
- ABBR is for machines only
- Abbreviations for end users
- Good old plain text
- The myth of doing it first time
- Plain text is usable and accessible
- ABBR and ACRONYM are not for end users
- Abbreviations for man and machine
- Conclusion
Checkpoint 4.2 has actually been one of the reasons why I never have considered trying to live up to Triple-A Conformance. With so unclear checkpoints we are better of not using them:
Checkpoint 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."
Checkpoint 4.2 has three major problems:
- Why do we have both an ABBR tag and an ACRONYM tag, and how should web page authors in any consistent way be able to choose the right one in daily life.
- Can it really be true that we shall use these tags for each abbreviation and acronym the first time they appear in our document?
- Are ABBR and ACRONYM only mark-up for the sake of screen readers, word checkers, search engines, etc., or are they also to be used visually for real people in graphical browsers.
1. ACRONYM is dead and out
I am not going to repeat all the arguments why it is impossible to distinguish between ABBR and ACRONYM in any sensible way that is workable for web page authors. This discussion is now history.
In the draft for XHTML 2.0 the tag ACRONYM does not exist any more. It is abolished. Only ABBR is still in business and the specification clearly states that ABBR is to be used both for abbreviations and acronyms. No need to distinguish.
2. ABBR and pronunciation
How do we indicate if an abbreviation is to be pronounced letter for letter or like a word (usually part of the definition of an acronym). The draft for XHTML 2.0 clearly states, and this statement was also in the specification for HTML 4.0, that pronunciation is presentation and should not be a part of mark-up: "When necessary, authors should use style sheets to specify the pronunciation of an abbreviated form".
It is probably only necessary to use CSS if we want to stop screen readers from using the expansion in the title attribute for pronunciation. If we want the screen reader to pronounce the abbreviation, the user agent might need a hint.
3. Only use ABBR when not in dictionary
If we are to believe the draft for WCAG 2.0, we should only use the ABBR tag for abbreviations and acronyms that do not appear unambiguously in the unabridged dictionary for the language.
We should only use ABBR when it is likely that some user agent will not understand our abbreviation. Even if the abbreviation is in the unabridged dictionary, we should use ABBR if different words or groups of words can be abbreviated the same way.
4. ABBR is for machines only
The drafts for WCAG 2.0 and XHTML 2.0 still need to clarify if ABBR is for machines only or if ABBR is also for direct human consumption. Many accessibility experts, authors of web pages, and graphical browsers get this issue wrong with disastrous consequences for usability and accessibility.
Note that the draft for XHTML 2.0 don't talk about what abbreviations users or the target group need to get expanded. The concern is only if the abbreviation is in the unabridged dictionary screen readers and other user agents are supposed to make use of.
The guidelines and specifications are not clear enough to avoid confusion. But it is difficult to deny that machines are the main focus whenever ABBR and ACRONYM are mentioned:
The HTML 4.0 specification: "Marking up these constructs provides useful information to user agents and tools such as spell checkers, speech synthesizers, translation systems and search-engine indexers."
5. Abbreviations for end users
When a text writer uses an abbreviation, an acronym, a symbol, a word or an expression not familiar to many of the readers in the target group, it has been Best Practice since the beginning of writing to add some extra information at least once, making the text easier to understand.
This should only be done if most or a big minority of the users need it. If only some users need it they should use a dictionary of their own choice or ask a friend.
6. Good old plain text
When additional information is needed, it can be done in several ways. Let me show two examples:
I use XSLT (Extended Style Sheet Transformation) to transform my articles from XML to XHTML.
In this case the abbreviation, acronym, symbol or unfamiliar word or expression is expanded in parenthesis following the short hand. But we can also start with the long hand and then introduce the short hand in parenthesis:
I use Extended Style Sheet Transformation (XSLT) to transform my articles from XML to XHTML.
There are other legitimate methods depending on the situation. Often it is more than good enough just to start using the short hand when the long hand has already been used. Readers will get the message.
The expansion or the introduction of a short hand can be done one or several times. We should consider the length of the text, and how difficult or unfamiliar the short hand is.
7. The myth of doing it first time
It is often stated that the expansion should be presented at least the first time the short hand is used. This is reasonable but not always true. The first time is not always the right time. It could make the beginning of a great text too clumsy, and even killing it. At times some suspense is ok.
It is not wrong to give a reader a moment to thing about it before presenting the full story on a silver plate. In text of high quality it is not uncommon first to include the long version or the short hand at the second or third opportunity.
Please note that we are not talking about the ABBR tag, but about how to expand abbreviations in plain text for end users.
8. Plain text is usable and accessible
It is and remains Best Practice to include the full version of an unfamiliar short hand at least once and often the first time the short hand is used. This is what writers have been doing for hundreds of years and what editors add to a text when a writer has forgotten the level of the target group.
Such long hand spelled out in the text is great on the screen and also when printed, and it works for users of mouse as well for as for the keyboard. Plain text can be scanned from a distance.
9. ABBR and ACRONYM are not for end users
Now consider what happens if ABBR and ACRONYM are used to expand abbreviations and acronyms for end users:
- The expansion can only be seen on the screen not when the document is printed.
- The expansion only works for the mouse not for ordinary keyboard users.
- The expansion is worthless for scanning. It can only be seen if you hover the mouse pointer over the short hand.
- The browser most people use, IE for Windows, does not support ABBR but only ACRONYM; and even this tag is only rendered with a tool tip. The user must hover the mouse pointer over every single abbreviation to find out where some additional information is hidden.
All the great natural usability and accessibility of plain text is lost if we use tags like ABBR and ACRONYM to serve expansion of short hand to end users.
10. Abbreviations for man and machine
The specifications and guidelines still need to make clear how to mark-up abbreviations when both user agents and end users need additional information. Here is an axample of how it should be done:
In my opinion WCAG (Web Content Accessibility Guidelines) is sometimes so unclear that we are better off not following the guidelines to avoid making things worse.
If WCAG is not in the unabridged dictionary of the language, user agents need the ABBR tag. User agents can not with certainty detect the meaning of the parenthesis.
The plain text in parenthesis is for end users. They even need expansion for many abbreviations in the unabridged dictionary in order to comprehend the text.
11. Conclusion
ABBR and ACRONYM are for machines only. Plain text is the only solution when abbreviations need to be expanded for human beings, for end users directly.
Graphical user agents, browsers like Mozilla and Opera, are wrong when they render ABBR and ACRONYM in a special color or with styles like a dotted or a solid line. This is misuse of structural mark-up meant for user agents only.
To prevent graphical browsers from presenting ABBR and ACRONYM visually, you could add this to your stylesheet:
abbr, acronym {color: black; text-decoration: none; border-bottom: 0px}
Graphical browsers are also wrong and they only add confusion to the whole issue, when they render the title attribute in ABBR and ACRONYM as tool tips.
The specification for XHTML 2.0, WCAG 2.0 and other relevant specifications, should specify that ABBR and similar tags are for machines only and that plain text is the only usable and accessible solution when abbreviations need to be expanded for end users directly.
Copyright © Jesper Tverskov, 2004
Last updated 2006-08-30