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:
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.
Copy & paste the code below to embed this comment.
Derek Pennycuff
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.
Copy & paste the code below to embed this comment.
Derek Pennycuff
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 <abbr> 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:
They say they are getting rid of the acronym tag and keeping the abbr tag for reasons unclear to most people.
should be:
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.
Copy & paste the code below to embed this comment.
Gia Fly
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.
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.
Copy & paste the code below to embed this comment.
Brian LePore
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.
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.
“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.
39 Reader Comments
Back to the ArticleBill Ward
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!!!
Jeffrey Zeldman
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:
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.
Derek Pennycuff
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.
Jeffrey Zeldman
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.
Derek Pennycuff
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.
James Edwards
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 <abbr> 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.
Christian Ziebarth
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:
But:
should be:
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.
Gia Fly
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.
Mark Priestap
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.
Alberto Romero
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.
Brian LePore
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?
Robert Wellock
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.
Alberto Romero
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?
Matthias Mauch
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.
Lars Kasper
(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 ”¦)
Agnar Ødegård
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.
Peter Foti
I’ve been searching for an <abbr> solution that would work with IE6, and this is it! ‘Nuff said!
Thierry Koblentz
“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.
Best US UK Poker Sites Review
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