AAA-level compliance is the ideal of accessibility, the bonus-round of accessible design: AAA-level compliant pages meet the needs of every group of users. AAA is achievable, but requires preparation and forethought. To create a forward-looking, fully AAA-compliant site, we need to execute a sort of hat trick: XHTML 1.0 and 2.0-compliant markup, a generous breadth of backwards compatibility, and real universal accessibility.
Article Continues Below
The WCAG Priority 3 checkpoints (and the WCAG 2.0 Level 3 Success Criteria) are clear enough in terms of purpose and implementation, but abbreviations and acronyms stand out as one of the trickier areas of AAA to implement well. In order to meet our three-part goal of standards compliance, backwards compatibility, and full accessibility, we need to give this aspect of our content a bit of thought.
WCAG Checkpoint 4.2, and version 2.0 Guideline 3.1 both require the expanded forms of acronyms and abbreviations to be available, and these guidelines are important to many groups of users. The elderly and those with learning or cognitive disabilities may have a difficult time remembering abbreviations (such as U.S. state abbreviations); learners of foreign languages are likely to be unfamiliar with abbreviations that native speakers take for granted (such as “inc.” or “lmtd.” in English); and users with visual disabilities can configure screen reading software to read the expanded forms of abbreviations, which greatly improves the flow of the text (imagine hearing the sentence “We invite our readers to join us for our Wisc. area potluck” without the abbreviation expanded).
For users or user-agents?#section2
Are these guidelines intended to be implemented in ways that provide expanded explanations to users directly, or are they meant to provide information to user-agents, which then have the responsibility of communicating this information to users? Many excellent articles on this debate exist, but I’m not convinced that the debate itself is useful. A different approach would be to say that available markup meets the needs of some users directly, while simultaneously providing information to user-agents, which is beneficial for other groups of users.
The point of including expanded forms of abbreviations is to make sure that users can access those forms if needed. The value of the abbr element lies in its ability to tell screen readers what they should read (thus improving the flow of spoken text), while also providing additional useful information to visual users with learning or cognitive disabilities (or those coping with language barriers). The assertion that abbr is structural is misguided, as the point of the tag is the content of its title attribute.
When we talk about accessibility, we are not talking only about users with visual disabilities. Many disabilities can affect a person’s ability to access text, and we want to both improve access and make it clear that accessibility aids exist on our sites. Visual presentation for abbr (as well as non-visual presentations discussed below) achieve this.
As web designers and developers, our job is to integrate text and markup in ways that best meet the needs and expectations of multiple groups of users. For AAA-level conformance, we need to effectively communicate expanded forms of abbreviations to everybody, requiring techniques focused simultaneously on users-agents and users directly.
This is where the hat trick comes into play: by taking an approach that is compliant with both current and soon-to-be-current standards, backwards compatible to non-compliant user-agents, and fully accessible (i.e. usable, and providing the same information to all users) we can achieve the effective communication we’re shooting for.
First Goal: Standards#section3
Our first goal is compliance with XHTML 2.0. In version 2, the acronym element has been deprecated, so we’re now using the abbr element for all shortened forms. This element has a new attribute in 2.0: full. The spec says that “the title or full attributes may be used to provide the full or expanded form of the expression” (emphasis mine); since full is not included under version 1, and we want to be compliant with both, we’ll stick with titles.
The basics#section4
The
DARPA was instrumental in the history of the internet.In this example, all XHTML 2.0 compliant browsers will provide the full definition in a tool-tip on mouse-over; many use a dotted underline to alert visual users that this information is available. Since we’re erring on the side of too much information, and for the sake of cross-browser consistency, we’ll add abbr { border-bottom-width: 1px; border-bottom-style: dotted; } to our styles. (Note: IE 6 does not support abbr: it doesn’t see it, you can’t style it, there’s no tool tip. Later, we’ll use this style defintion as part of our IE 6 workaround.)
Also in this example, if a JAWS user has the software set to read expanded abbreviations, he or she hears: “The Defense Advanced Research Projects Agency was.” If not, JAWS speaks “The darpa was.”
We’ll want to let users know that our site is AAA compliant and that explanations are available for acronyms and abbreviations, and to let users of screen readers know there is extra information available if their software is set to read it. The site’s accessibility policy is a good spot for this kind of information.
JAWS and initialisms#section5
CSS2 has defined properties for screen-reading software that are meant to help separate abbreviations that should be spoken as whole words from those that should be spoken as initials. However, JAWS 7.0 (the latest version) does not support these, nor am I aware of any user-agents that do.
Who’s left out#section6
IE 6 users won’t see the tool-tip in the above example, and there are two other groups of users whose needs are not met by this solution: visual users with motor disabilities who cannot mouse over text to activate tool-tips, and users of text-only browsers and Braille displays. We’ll come back to these groups once we’ve sorted everything else out.
Second goal: backwards compatibility#section7
The next part of the hat trick is backwards compatibility. IE 7 will support the abbr element; IE 6 does not. IE 6 supports the acronym tag, but as mentioned above, this tag didn’t make it into XHTML 2.0, so we need a better solution. Fortunately, even older versions of JAWS will read the title attributes of abbr tags, so the only users we’re concerned with at the moment are IE 6 users, to whom we want to communicate the availability of the tool-tip definitions.
One possible solution (although not the best way to go) is with span tags:
.abbr {
border-bottom-width: 1px;
border-bottom-style: dotted;
}
The
DARPA was instrumental in the history of the internet.The DARPA was instrumental in the history of the internet.
JAWS speaks:
The Defense Advanced Research Projects Agency was instrumental in the history of the internet.
This works because JAWS doesn’t read title attributes for span tags, so JAWS users don’t get redundant information, but IE 6 users get the information they need. This method demonstrates the problem and one possible solution to it, and I’ve only mentioned it for that reason—don’t worry, those spans are gone in the next section. The solution we are looking for is one that remains accessible to screen readers, communicates the availability of tool-tips to users no matter what browser they are using, and is accessible to users of Braille and text-only displays as well as users with motor disabilities, who should not be forced to mouse-over text to get tool-tips.
Final goal: full accessibility#section8
The obvious answer for users with neither screen readers nor mice is contextual (written out) explanations of abbreviations. Contextual explanations are always the best, but are not always the most aesthetically appealing.
In the DARPA example above, a contextual explanation is fine:
The Defence Advanced Research Projects Agency (DARPA) was instrumental in the history of the internet.
However, for high-frequency abbreviations (which must still be explained for AAA-level conformance; AAA means we make no assumptions), contextual explanations pose some problems. Consider this example:
Mr. John Smith Sr., CEO of Happy Ducks Co., Ltd.
Were we to expand these abbreviations in context, the results would be 100% accessible to everybody, but pretty messy. When it comes to written out definitions, these super-high-frequency abbreviations are the straw that breaks the camel’s back: users with learning disabilities such as dyslexia, cognitive disabilities such as dementia, and other users including children, the elderly, and foreign language learners may all require explanations, but we can’t rely on tool-tips because they don’t meet the need of users who do not use mice. (Note: while older drafts of WCAG 2.0 mentioned a standard of whether or not the term was included in a dictionary as a basis for needing an explanation, that standard is (thankfully) gone in the latest version, and for AAA we are going to define everything.)
The elegant solution is with links to a site glossary. To be AAA compliant under WCAG 2.0, we’ll likely want to have a site glossary anyway, with definitions of any technical terms or jargon in our content, as well as phrases or words used in non-standard ways. By including abbreviations in our glossary, we’ve taken the extra accessibility step that sets the best sites apart from the herd.
There are many benefits of using links to a glossary:
- The
atag’stitleattribute ensures that IE 6, which does not give tool-tips forabbrtags, will provide tool-tips for our abbreviations. - This technique allows us to style the links with a dotted underline, communicating their function as explanations to visual users.
- Since these are links, text-only users and users who have difficulty with mice can now tab to them, and use the keyboard-accessible links to access the information that other users get via the tool-tips or screen readers.
Here’s our example:
a:link.gloss,
a:visited.gloss,
a:hover.gloss,
a:active.gloss {
color: #000000; /* should be the same color as text */
text-decoration: none;
border-bottom-width: 1px;
border-bottom-style: dotted;
border-bottom-color: #000000; /* for IE 5, same color as above */
font-style: normal; /* for use with dfn */
}
The Internal Revenue Service (IRS) is one of the most maligned
agencies of the
U.S. government.
Mr. Mark W. Everson, the Chairman of the
IRS, would likely be the least
popular man in America if more people knew his name. However,
everybody in the U.S. certainly benefits from the IRS’s
work in the form of mail service and roads.It looks like this:
The Internal Revenue Service (IRS) is one of the most maligned agencies of the U.S. government. Mr. Mark W. Everson, the Chairman of the IRS, would likely be the least popular man in America if more people knew his name. However, everybody in the U.S. certainly benefits from the IRS’s work in the form of mail service and roads.
JAWS speaks:
The Internal Revenue Service left paren IRS right paren is one of the most maligned agencies of the United States government. Mister Mark W. Everson, the Chairman of the Internal Revenue Service, would likely be the least popular man in America if more people knew his name. However, everybody in the U dot S certainly benefits from the IRS’s work in the form of mail service and roads.
The $64k question is: how do we balance in-text and marked-up explanations? WCAG version 1 instructs us to “specify the expansion of each abbreviation or acronym in a document where it first occurs,” while WCAG version 2 requires that “a mechanism for finding the expanded form of abbreviations is available.” We seem free to do this however we choose, provided that we give an expanded form (in some way) the first time we encounter each abbreviation or acronym.
The “first time” a user encounters an abbreviation could be anywhere if a page is navigable via named anchor links, and since we’re shooting for AAA, we want to err on the side of too much explanation anyway. From a user-centric perspective, it’s good to mark up some subsequent occurences, as we can not assume that all users will be able to recall the expansion from a single instance, and we want to provide explanations at the point they are needed. My general approach is as follows:
- The first time an abbreviation occurs after each heading, expand it contextually, except for super-high-frequency abbreviations, or in situations where aesthetic or stylistic considerations dictate otherwise; mark these up.
- In each paragraph after the first paragraph (under each heading) where the abbreviation is explained, mark up the first occurence of each abbreviation.
- For those super-high-frequency abbreviations, don’t drive yourself nuts; realatively infrequent glossary link markup for these is fine, although I advise using scaled-back markup (
abbrtags with atitleattribute only) for screen readers at every occurence: “Mister” is a lot softer on the ears than “M R”. - Where stylistically appropriate, try to vary contextual and marked up explanations.
These are subjective decisions; use your best judgement and pay attention to named anchors and the distance between abbreviation explanations and users should be able to find what they’re looking for.
A note about styles: It would be nice to do this without having to define a class (e.g. abbr a { … styles … }) but because IE 6 does not support abbr this won’t work. It will work for the instances below where we’ll use dfn, but for consistency I’ll keep using my gloss class in those examples.
Future improvements#section9
Once XHTML 2.0 compliant browsers are the norm, we’ll be able to tighten this markup by including the href within the abbr tag. The above example is as clunky and redundant as it is to ensure both forward and backwards compatibility while maximizing content accessibility. We could cut the abbrs entirely and handle this exclusively with anchors, but that would break the trick described below, and would take us further from the semantically preferable methods we’ll be able to use once browsers become XHTML 2.0 compliant.
Notes about JAWS#section10
JAWS identifies links to users by speaking “link”, “visited link”, or “this page link” as appropriate. However, in the example above, JAWS does not see these links, and JAWS users can not access them. Here’s why:
textJAWS encounters the abbr tag, and treats all following text (including markup) as the defined term until it encounters the closing tag. The result is that links enclosed within abbr tags are dropped.
In this case, the link takes users to a glossary entry that provides the same information that JAWS would speak, and I believe that this is acceptable from an accessibility perspective. We’re trying to provide abbreviation explanations, and even if non-visual users can not access the same link that visual users can, they still receive the information that the link provides. JAWS users won’t be distracted by hearing “link”—and following the link would provide redundant information for these users anyway. That said, taking links away from one group of users feels wrong, even if they do get the same information via screen readers, so I am interested in suggestions for improving this method.
We could, of course, reverse the nesting of the tags like this:
text
…and JAWS would then provide access to the link. The trade off is that it will also speak “link:”, obstructing the flow of reading with redundant information. In this case, the a title becomes IE 6’s tool-tip, because it does not support abbr, and the abbr title becomes the tool-tip for browsers that do support abbr. The abbr title is also the text that JAWS speaks.
Experimenting with JAWS#section11
I’ve tried pulling the href from the anchors to test if JAWS will speak these correctly if they are not links, and the answer is yes. This is because JAWS is speaking the abbr title. If you will not be using a glossary on your site, you could do it this way (replacing the as with spans so IE 6 users receive the style), but this won’t work for examples I’ll be addressing shortly.
Our site is shaping up nicely from an accessibility point of view: we have provided explanations of all abbreviations and acronyms in a way that is accessible to all of our potential users. Let’s not drop the ball here: we can use the same techniques, with some slight adjustments, to execute our hat trick for technical language and foreign-language phrases as well.
Foreign phrases#section13
Phrases from other languages are an interesting challenge: we want a tool-tip explanation that’s helpful for visual users who can see the phrase, and we want screen readers to read the phrase out and also provide a link to the site glossary for non-visual users who would like the explanation.
Foreign phrases add a certain je ne sais quoito one’s prose.Visual browsers display this:
Foreign phrases add a certain je ne sais quoi to one’s prose.
JAWS speaks this:
Foreign phrases add a certain link: je ne sais quoi, to one’s prose.
I’m using a dfn tag for the tool-tip that users expect (as opposed to a title attribute in the a tag) because I’ve used the lang attribute of the a tag, and therefore screen readers are expecting everything enclosed within these tags to be in French. If I had an English-language title attribute within tags that included the lang attribute, screen readers would pronounce the title using French pronunciation rules. Additionally, this takes advantage of the fact that JAWS does not read the title attributes of dfn elements, so JAWS correctly speaks the passage in the same way as a human reader (we do not want JAWS to speak the tool-tip text in place of the phrase), while indicating that the glossary definition is available by saying “link”.
Note that here, JAWS will speak “link”, and JAWS users can tab to the link, because there are no abbr tags. This is a good thing: for glossary entries that define the terms given (and especially where we’ve used markup such that screen readers speak something other than the tool-tip information), we certainly want to make sure that users of screen readers know that definitions are available in our glossary, and can access them.
A note about hrefs: In the IRS example above, we could pull the href from the a tags (for a case where the site is not using a glossary) because JAWS would still read the abbr title. In this example, and the examples below, we can’t get away with this, because JAWS will read neither the dfn title nor the a title in the absence of a link.
Jargon#section14
Here’s another situation in which we want JAWS to speak one thing and have a tool-tip that shows another:
In audio technology, the
root-mean-square
statistic is a useful method for generalizing
about output.Visual browsers display this:
In audio technology, the root-mean-square statistic is a useful method for generalizing about output.
JAWS speaks this:
In audio technology, the link: root dash mean dash square statistic, is a useful method for generalizing about output.
Again, there’s a tool-tip and JAWS speaks “link:” to direct interested users to the glossary.
Roman numerals#section15
Another good application for this trick is the Roman numeral. We want to make sure our Roman numerals are accessible to users who are unfamiliar or have difficulty with them, but also make sure JAWS speaks them naturally.
King Henry VIII
had many wives.Please read chapter
VIII for homework.Visual browsers display this:
King Henry VIII had many wives.
Please read chapter VIII for homework.
JAWS speaks this:
King Henry link: the eighth, had many wives.
Please read chapter link: eight, for homework.
Note that in these examples, I’ve moved the a
tags to the outside of the dfn tags, because visual
browsers display the last title attribute they
encounter, but that’s not what we want JAWS to speak.
AAA-level compliance in practice#section16
This probably looks like a lot of “extra” code, but there are working methods that help minimize keystrokes and time required while maintaining this degree of accessibility. For each of my sites, I keep a plain text file of abbreviation markup from which I can cut and paste when necessary. It includes entries like these:
EJWGMATWhen I encounter a new abbreviation (or other glossary entry), I paste the markup into my abbreviations file in alphabetical order so that I can quickly find it for the next occurrence.
One very strong argument for only using contextual abbreviation explanations is that marked up explanations will not occur in a printed document. This is certainly worth bearing in mind as we decide which abbreviations to explain contextually and which to mark up, but in fairness, the links on the printed document won’t work either, and neither will JavaScript or Flash. We have to accept that when we send an HTML document to the printer, there is an inherent loss of functionality, and that’s hardly an excuse to not use HTML features that many users find helpful.
(Generated content in CSS may be used to expand abbreviations for print, using the techniques discussed in “CSS Design: Going to Print,” remedying some of these problems. Note also that JavaScript may be used to generate a page glossary for print, using the techniques discussed in “Improving Link Display for Print.” —Ed.)
By way of conclusion, here is a passage from Richard Mitchell’s Less than Words Can Say:
…as long as we have a lawyer in view, ain’t they something? We read with pitying shakes of the head the disclaimers and demurrers at the bottom of the contract. We like to imagine that we, just plain folks, are somehow, deep down where it really counts, superior to those pointy-headed word-mongers with all their herinafters. Nevertheless, we do what they tell us to do. We always remember that if we can’t figure out from their language what we’re required to do, and if we therefore fail to do it, it isn’t the writers of the jargon who will be called to account. Our sense of superiority is an illusion, a convenient illusion from somebody’s point of view; in fact, when we read the contract, we are afraid. It is the intent of that language to make us afraid. It works.
Mitchell is writing about the relationship between language and social class: those in positions of power use language differently from those over whom they wield that power, and the lesson we should take from the observation is important.
If the content of our website is accessible only to users who are native speakers of our language and who do not live with any sort of disability, then we are perpetuating a situation in which second-language learners, children, the elderly, and people with disabilities are second class citizens. By taking the time to pull off the accessibility hat trick, to make our content standards compliant, backwards compatible, and fully accessible, we allow all users to approach our content as equals. That’s what AAA-level conformance is about.
For truly accessible content, we should handle abbreviations, acronyms, and foreign phrases is ways that are:
- Standards compliant in a way that works with current technologies while looking forward to forthcoming versions of those technologies.
- Backward compatible, especially in ways that communicate the availability of accessibility aids to users (e.g. dotted underlines for abbreviations for IE 6 users).
- Fully accessible, including explanations of abbreviations that are generally taken for granted, and the use of a site glossary and links to it for users who can not or do not use mice for input.
Sample site glossary#section20
Here is a sample site glossary to illustrate the resulting context of glossary links described above.
- IRS
- Internal Revenue Service—the agency of the United States government responsible for collecting taxes
- je ne sais quoi
- a French phrase meaning “a certain indefinable quality”
- Mr.
- Mister—in English, a polite form of address for a man
- RMS
- root-mean-squared—a technical term referring to the average continuous output of an amplifier; it is measured by calculating the average (mean) of the square roots of all available measurements, and then squaring (multiplying by itself) this mean
- Roman Numerals
- a system of numbers commonly used for referring to reigns of monarchs, centuries, and in musical notation; each letter has a value (e.g. I=1, V=5, X=10, L=50, C=100, etc.), and the total value for the number is the sum of its component letters (e.g. XII = 10 1 = 12); when a letter comes before another letter of a greater value (e.g. XL), the value of the lower-valued letter is subtracted from the value of the immediately following letter (e.g. XL = 40, XLIII = 43)
- U.S.
- the United States of America—a common abbreviation in English
