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.
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 <abbr title="Defense Advanced Research Projects Agency">
DARPA</abbr> 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 <span class="abbr" title="Defense Advanced Research Projects
Agency"><abbr title="Defense Advanced Research Projects Agency">
DARPA</abbr></span> 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 <abbr title="United States"> <a href=
"glossary.html#US" title="United States" class="gloss">
U.S.</a></abbr> government. <abbr title="Mister"><a href="glossary.html#Mr" title="Mister" class="gloss">
Mr.</a> </abbr> Mark W. Everson, the Chairman of the
<abbr title="Internal Revenue Service"> <a href="
glossary.html#IRS" title="Internal Revenue Service"
class="gloss">IRS</a></abbr>, 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:
<abbr title="Jaws speaks this"><a href="href"
title="Visual browsers display this">text</a></abbr>JAWS 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:
<a href="href" title="IE displays this"><abbr
title="JAWS speaks this, and other browsers display this">text
</abbr></a>…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.
Don’t stop now!#section12
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 <dfn title="French:
indefinable quality"><a href="glossary.html#jenesaisquoi"
lang="fr" class="gloss">je ne sais quoi</a></dfn>to 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 <dfn title="see glossary">
<a href="glossary.html#rms" class="gloss">root-mean-square
statistic</a></dfn> 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 <a href="/glossary.html#romannums" title="the eighth"
class="gloss"><dfn title="Roman numeral eight">VIII</dfn></a>
had many wives.Please read chapter <a href="/glossary.html#romannums"
title="eight" class="gloss"><dfn title="Roman numeral eight">
VIII</dfn></a> 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:
<abbr title="Equal Justice Works"><a
href="/site_help/glossary.php#ejw"
title="Equal Justice Works" class="glossary">EJW</a></abbr><abbr title="Graduate Management Administration Test"><a
href="/site_help/glossary.php#gmat"
title="Graduate Management Administration Test"
class="glossary">GMAT</a>When 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.
Printing#section17
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.)
That’s it#section18
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.
Quick reference#section19
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 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
In the article, we are told that JAWS will read the title attribute of abbr elements, but will not read the title attribute for span or defn elements. Would I be correct in assuming that abbr and acronym are the only elements that JAWS will read the title tag if it is present? I am particularly curious as to what JAWS would do when it encounters a blockquote with a title attribute.
Are there any other elements that JAWS would read the title attribute in place of the element? I can’t imagine that it would, but I would hate to find out that JAWS replaced the glossary at the end with the phrase “Site Glossary”.
I can see one very big problem with the suggested glossary approach; if users (particularly screenreader users) follow a definition link to the site glossary (either to look up the term if they understand the link’s purpose, or because they are curious why that term is linked at all), they have no way of returning to the point on the page that they were reading.
They would have to click the Back button, and then presumably either start from the beginning or switch to Links mode and move through all the links on the page until they find the one they just visited (inconvenient, especially if that term is linked more than once on the page).
Instead of having a link class .gloss, why not just define abbr a to do what you want? Seems unlikely you’ll wind up with non-glossary links inside an abbr tag; if you do, you could always define a class for them.
“Our first goal is compliance with XHTML 2.0.”
What on earth _for_? XHTML 2.0 is currently only a work in progress. According to the latest spec “[it] is the seventh public Working Draft of this specification. It should in no way be considered stable, and should not be normatively referenced for any purposes whatsoever.”
So why avoid the IE-friendly (and valid) element, purely to support an unfinshed standard that’s not supported by any existing browser and whose own spec tells you not to use it. Given that the W3C are the only people on earth slower than the IE development team (any sign of them finishing the CSS2.1 spec?), I wouldn’t hold my breath waiting for XHTML2. Heck, we’ll be on to IE9 by then.
There’s a lot of useful and thought-provoking stuff in this article, but it’s marred by this piece of gotta-be-on-the-bleeding-edge geekery.
I will have to assume the article was mainly ‘theoretical’ and many of the techniques would probably clash. It’s fine for those who know what they are doing already. Though in the wrong webmaster’s hands they’ll believe Triple-A is just one single normative checklist, it didn’t help by referencing the WCAG 2.0.
Parts of the article were useful but it appeared like it was hyping XHTML 2.0, which has hardly been completed. Some modern User Agents cannot cope with anything greater than HTML 3.2 in today’s world.
…but it’s certainly worth mentioning that, taking the wording of WCAG 1.0 strictly, it’s practically impossible to achieve (and 2.0 is currently even worse, so much so that plans for revision include a different way of being able to claim AAA without needing to cover all p3 success criteria). just looking at priority 3 in 1.0, you have whoppers like “11.3 Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.)”. i can’t see any site being able to ever claim complete adherence to this. or how about “14.2 Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page”?
oh, small typo: the english abbreviation for “limited” is “ltd.”, not “lmtd.”
Very nice article. I think it’s a bit over the top to even support text-only browsers. It however proves that one can, which is pretty cool.
I’m not sure though that the following isn’t semanticly correct:
root-mean-square
statistic
Matthew Pennell raises a good point about a way back from glossary links. Alt + left arrow is JAWS’ equivalent of a back button, and it returns to the location of the referring link, from which the user can continue reading.
Quote: “The assertion that abbr is structural is misguided, as the point of the tag is the content of its title attribute.”
I have to disagree with that. The tag is structural – otherwise you would be using a span with a title attribute.
Just because it doesn’t work well with screen-readers doesn’t mean it’s not structural… I don’t like the inference that the DOM is only there for user-accessability reasons.
Using Opera 8.5, I cam across some interesting problems with some of your abbreviations.
Specifically, the ones coded as, eg, WCAG. These appeared with a dotted underline, but I could only get the tooltip if I moused-over the dotted line, as soon as the cursor moved over the text, the tooltip disappeared.
I couldn’t even see a declaration for .caps – given that the content was typed in capitals in the source, what is the purpose of it?
bq. While it’s true that XHTML 2.0 isn’t yet a viable spec, I think there’s value in looking ahead — particularly when the spec-in-progress seems to be moving toward a good decision like the removal of the acronym tag.
will be with us for a long time yet. IE6 will not be eradicated at the drop of a hat (unfortunately!), and the fact is that using the acronym tag does work more readily for most current browsers than abbr does, once you have found ways to hack it to work in IE6 … only to find this breaks it in other browsers.
So how about a mongrel … OK, so it wouldn’t be valid XHTML 2.0, but would nesting the tags like that work across different browsers?
Excuse my ignorance, but in the original article and all subsequent posts, _no one_ defined the acronym *AAA*. Would someone be so kind as to give me a clue? I’d appreciate it.
Be careful with the links though, (13.1.2) as all anchor elements are required not to use the same link text to refer to different resources.
Personally, I find this a very thought provoking article, but there is too much code for my liking… I will stick to providing support for the good browsers, and sod IE6, not worth my time catering for every one of its deficiencies (but don’t mind spending a few/many hours fixing its CSS bugs).
bq. but would nesting the tags like that work across different browsers?
In theory, no. XHTML 2.0 is strict, strict, strict. That means you’d have to serve the page as application/xml and not text/html. Isn’t it supposed to be that the rendering of the page would then fail in a compliant browser since the page is technically an application and not a text file?
As long as we’re speaking of abbreviations and semantics, that “e.g.” in the glossary should have the title “Latin; For the sake of example,” (or “Latin; For example”) rather than merely “for example.” I only say this because that is essentially what was done for the French term mentioned earlier.
I agree with this statement.
In the article, I noticed that there is a single use of “i.e.” that is served with a Latin language type, but the title attribute’s value is “that is”, but this was not done for “e.g.”. Why was this?
The definition of RMS in the glossary is not quite right. RMS is the square root of the average of the squares, and *not* the square of the average of the square roots.
Once again, an article on accessibility seems to alienate most web pros. Indeed the greater the number of A s it’s trying to achieve the greater the reaction. This is because ‘accessible to all’ is an unreasonable, if not unattainable, goal.
For instance, I would argue that the under-10 age group is a larger segment of web users than the disabled. Therefore, all web pages should be written in the style of ‘Janet and John’ books to make them readable by this group and, as a side-affect, those adults who are ‘literally-challenged’ though it will probably turn most of the rest of us off as well as making almost all the web sites I’ve ever visited inaccessible including this one. I fully expect the next issue of ALA to not contain any words with more than 3 syllables, if you’re serious.
Having said that, I have no problem with making sites as accessible as possible to THE AUDIENCES THEY ARE AIMED AT. Indeed, I try to make my designs comply to double-A guidelines though I’m not quite there yet. My biggest problem is that I write in English, for an English speaking audience, but live in a non-English speaking country so I have to remember to use the LANG attribute whenever I use local placenames, real names, etc. and HREFLANG whenever I link to a local site.
This article was useful for an insight into how a screen reader works, information that I have sought in the past without success, but what is really needed is an assistive-technology equipped browser (come on you Open Sourcers) that designers can use to test pages, as they do with the visual types, without having to fork-out the obscene prices that I’ve seen for currently available apps. That’s another thing! Perhaps instead of their tendency to bleat, organisations for the disabled should commission someone (mozilla.org??) to write one. That would be a real benefit to their constituency as well as the people who produce the sites. In the meantime, we have to rely on, mostly contradictory, articles on accessibility or design to the technical standards and hope for the best.
On a lighter note, you missed an abbreviation in ‘Mark W. Everson’. I want to know what ‘W’ stands for. It must be important or it wouldn’t be there.
That’s true of Web Content Authoring Guideline (WCAG) 1.0, but there’s no such demand in the current Working Draft 2.0 (so far as I have found).
In fact, conformance is defined relative to a technology baseline. AAA may not even require achieving all level 3 checkpoints.
Which is just as well, because (despite this excellent article) AAA as it stands is either impossible or undesirable for any website that is aimed at a specific audience.
bq. Be careful with the links though, (13.1.2) as all anchor elements are required not to use the same link text to refer to different resources.
No problem. You have
css and HTML, where the destination of the two links is different – what comes after the # does count.
I think it’s funny that you never defined what AAA and JAWS are. One can guess from context that AAA is some kind of standard for accessibility and that JAWS is a program that speaks the text of a Web page for the benefit of blind people, but you never say what they are or link to sites that explain them further…
But A List Apart is for general Web design issues, not just those specific to your field, so you need to define these acronyms. Especially when defining acronyms is the subject of the article!!!
The W3C’s nomenclature _is_ confusing. A conformance means that Priority 1 checkpoints are satisfied; AA conformance means Priority 1 and 2 are satisfied; and AAA conformance means all accessibility checkpoints are satisfied:
bq. Conformance Level “Triple-A”: all Priority 1, 2, and 3 checkpoints are satisfied
The definition is from a “link”:http://www.w3.org/TR/WAI-WEBCONTENT/ at the very beginning of the article.
See, the author did tell you.
Yes, we were told, but in a way that’s pretty easy to miss. Just because an accessability issue has been addressed does not mean it’s been addressed in an obvious or usable way. Perhaps we need to create a new web design discipline, the usability of accessability.
We editors failed to notice that the term had not been defined within the body of the article, or in an obvious, can’t-miss-it-way.
For my part, I must have assumed that anyone who would read such a specialized article would be familiar with JAWS and with the W3C’s WCAG 1.0 conformance level nomenclature. It must have seemed to me that people who weren’t familiar with that level of arcana would have no reason on earth to read the article. (None of this would have been conscious. I’m reverse engineering my assumptions.)
I regret that some readers felt left in the dark on these points.
I didn’t need either explained to me in any more detail. But I also didn’t need U.S. or Mr. explained to me. Or to pick items from the actual body text rather than examples, I didn’t need IE or e.g. explained to me. Doesn’t bother me one bit that they were coded for further explaination, wouldn’t have cared if they weren’t. But, apparently, it makes some people feel witty and/or important to point out ironies, ommissions, or otherwise enter into intellectual pissing contests with ALA writers and staff (or so it seems to me, I’ll stick with my subject line and not speak for others).
I was actually attempting to make a serious point about the difference between achieving compliance with accessability guidelines by following the letter of the law vs. the spirit behind them. I’m sure I’m preaching to the quior with Jeffrey and Erin and Colin, and I’m not trying to say the failure of some audience members (myself included) to follow the introductory links provided and properly digest their content before diving into the article indicates a failing on the part of Colin or the ALA editorial staff. It’s a perfect illustration of Murphy’s Law. Every time you make something fool proof, you find a better fool.
We can look at this and try to look down our noses at professionals who write articles for ALA or otherwise try to contribute to the ALA community; or we can have a little chuckle and make a mental note that even with a site written and produced by professionals and with an audience comprised of professionals or otherwise educated insiders, slip ups can happen.
This particular slip up was trivial and relatively unimportant given the target audience (knit picky lot we may be), but I do think it serves to illustrate the SNAFU (Situation Normal, All Fouled Up) principle pretty well.
This is an interesting article, but the practical examples are all very hacky and make huge assumptions about the behavior of devices.
What really stuck in my mind is “JAWS does not read the title of span elements” – now don’t you mean “JAWS, in the version I’m using and the configuration I have, does not read the title of span elements”. JAWS has a multitude of options for controlling the verbosity of its output, when titles are read or not read, and how much meta-information is given.
Likewise, the trick of using an anchor inside an abbreviation that JAWS doesn’t see as a link – I don’t know if any of its options could affect that behavior, but even if it’s solid, it seems to me rather arbitrary – there’s no good reason why it should do this, it just happens to do this.
And what about other screenreaders? Earlier versions of JAWS, Windows Eyes, Hal or Connect Outloud?
There’s an important proviso that this article overlooks, which is that users themselves must be prepared to take some responsibility, and in this case “users” means browser vendors as much as individual end users – the fact that IE doesn’t support is IE’s problem; if individual users find themselves inconvenienced by this, they have technology choices; if JAWS users want to hear title text, they have the option to turn it on.
It is clear to me that an acronym and an abbreviation are two different things. Yes, they are similar, but to me they are different enough that both the ABBR and ACRONYM tags should be preserved. I believe the article said something to the effect of “The days of surrounding abbreviations with acronym tags are numbered.” Well, I, for one, have never surrounded an abbreviation with an ACRONYM tag and just because maybe some people have doesn’t mean the ACRONYM tag should be deprecated.
That brings me to another point. I know that within an XHTML document that tag and attribute names should be in lowercase but in articles such as this one I feel it actually helps to display them in uppercase. However, it seems like everybody feels they are going to violate some unwritten XHTML protocol by displaying a tag name in uppercase even when outside of an XHTML document. This always rubbed me the wrong way but I never said anything until I read this article and realized how much it would’ve helped for mentions of tags within paragraphs of text (not within actual sample snippets of code) to be in uppercase. So it is okay to write:
bq. css
But:
bq. They say they are getting rid of the acronym tag and keeping the abbr tag for reasons unclear to most people.
should be:
bq. They say they are getting rid of the ACRONYM tag and keeping the ABBR tag.
I can’t go back and look at the article now without opening a new tab and hunting it down again and I think I remember that instances of tag names may have appeared in a slightly different font but even if that was the case it wasn’t different enough . . . at least for me.
By the way, I honestly did not know what JAWS was while reading this article (although it slowly began to dawn on me through context clues) and a tool tip would’ve helped. I’m not bragging here but I am only semi-geeky. Geeky enough to know exactly what XHTML stands for though.
Re: imagine hearing the sentence “We invite our readers to join us for our Wisc. area potluck”? without the abbreviation expanded
This is an interesting example, because the difficult word for many people will not be “Wisc.” (Wisconsin) as the author apparantly thinks, but “potluck”. Potluck is a shared meal where the guests bring the food – similar to “potlatch“.
Assume this example is real. When you’ve decoded “potluck”, the social factors are a much bigger problem. How do you decide which dish to bring, whether you should cook something or buy take-away, how much to spend, will some foods cause offense? Nightmare!
My point it that, if you try to explain everything that will not be obvious to everyone, this is not just a matter of expanding abbreviations. You need footnotes, references to an Encyclopedia, and probably a contact address for advice. You will certainly end up doing a lot of work and may still not satisfy everyone.
I agree with Mike Stone in comment #19.
Accessibility is wonderful and thoughtful and often delightful, but accessibility for one group can be inaccessiblity for another group. The audience is indeed key.
That said, the article was quite informative and useful.
I was just reviewing the article whilst coding a page for a new site, and I came across with a link formed by the next piece of text _*F1 Grand Prix*_.
I was trying out the proposed _glossary_ technique for expanding the words “Formula 1” and noticed I was nesting an ANCHOR tag inside another one!
Any comments on this issue?
Aside from that, I found the article very useful and thought-provoking, as others have said.
Earlier today I was looking at a page I was updating to add acronyms (I do not believe in getting rid of them because the current working draft is leaning against it, once it gets closer to/is ratified I may change my stance) and abbreviations and I found that my global search and replace caught an acronym within the alt text of an image. Must I expand the text in this case? How should one handle this?
In XHTML 1.0 nested anchors are illegal: “a must not contain other a elements.”
As for alt text abbr. depends on the audience and whether it occurs in the webpage. Though typically it would be deemed sensible to use the expanded form or parenthesis under most circumstances. Again the title attribute will come into play, if the image is meaningful enough.
bq. In XHTML 1.0 nested anchors are illegal: “a must not contain other a elements.”?
I know, that is what I was asking: The article suggests inserting a link to the glossary page as well as the ABBR tag, but what happens if we have an abbreviation that is already inside a link?
After reading your article and found following text segemnts
– Our first goal is compliance with XHTML 2.0
– IE 7 will support the abbr element;
i ask me, is this article for the future or is this article really a suggestion for good web sites?
Please note that XHTML 2 does not exist as a specification and IE 7.0 doesn’t work with the abbr element. It don’t know which Version of IE 7.0 you use, but the Version which is shipped with Windows Vista Beta 1 ignore the abbr Element.
Next, i tested IE 7.0 with XHTML 1.1 and the Recommendation of W3C to serve XHTML 1.1 as “application/xhtml+xml”. IE 6 can’t work with this. And IE 7.0? He open it as a simple text document like open an XML document without DTD.
So i ask me XHTML 2.0 and IE 7.0 are really good samples?
Aside from that, your article is really good.
# I do not understand the article’s fuss about XHTMLÂ 2. It will last years until that specification is final, and it will last even more years until most browsers will get it right. And then there will still be various Internet Explorers around and we cannot use XHTMLÂ 2 with them. As it is not backwards compatible, we are forced to send HTML to the browsers. XHTMLÂ 2 is a technology for the back end.
(Actual browsers don’t get HTML 4 or CSS 2 right. Those specifications are from last century, eight years old! And instead of fixing bugs and implementing complete and correct support for HTML 4.01 and CSS 2.0 [or CSS 2.01 at least] and preparing for CSS 3, browser vendors are making up new gimmicks for “HTML 5”?. But I am digressing “¦)
# Instead of a class=”gloss” for the links, one could use the more semantic rel=”glossary” (known from the LINK element, also allowed for the A element). But, of course, Internet Explorer does not know about attribute selectors, so you will not be able to style rel-links and have to stick to classes.
This article is almost screaming for PHP or similar language. With PHP one could define a list of words (abbr-list) with all the CSS code one could wish for, have a script run through each page and replace every occurence of any abbreviation in the abbr-list with proper coding. This way, you wouldn’t have to type every code out. And it would be easy to update which CSS code you want to put in the document as the misc. standards evolve.
You could with minimal extra work have PHP serve different abbr-lists depending on what browser the reader is using to get the best of all worlds.
I’ve been searching for an solution that would work with IE6, and this is it! ‘Nuff said!
“Using Javascript to expand abbreviations.”:http://www.tjkdesign.com/articles/how_to_expand_abbreviations.asp
Two different solutions actually:
– one script removes the TITLE attribute from the ABBR element, then the expansion of the abbreviation is done in plain text followed by the ABBR inside parentheses. Further occurrences of that abbreviation are left untouched.
– the second script creates a glossary on-the-fly; it parses the document to build a collection of ABBR and TITLE values then creates a Heading and a Definition List containing all the element/value pairs.
i thought this was a great article and if you need quality online casino, bingo or poker reviews take a look at http://www.online-casinos.co.uk