Discuss: The Accessibility Hat Trick: Getting Abbreviations Right
by Colin Lieberman
- Editorial Comments
22 you missed two important ones
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!!!
posted at 06:23 pm on January 18, 2006 by Bill Ward
23
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 at the very beginning of the article.
See, the author did tell you.
posted at 07:28 pm on January 18, 2006 by Jeffrey Zeldman
24 Hiding in plain sight
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.
posted at 01:34 pm on January 19, 2006 by Derek Pennycuff
25
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.
posted at 03:10 pm on January 19, 2006 by Jeffrey Zeldman
26 Can't speak for everyone
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.
posted at 11:28 pm on January 19, 2006 by Derek Pennycuff
27 Good theory, but the examples are too hacky to use
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.
posted at 09:41 am on January 20, 2006 by James Edwards
28 Don't lose the ACRONYM
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:
<abbr href=�glossary.htm#css� title=�Cascading Style Sheets�>css</abbr>
But:
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.
posted at 02:10 pm on January 20, 2006 by Christian Ziebarth
29 Untitled
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 “[url=“http://en.wikipedia.org/wiki/Potlatch”]potlatch[/url]”.
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.
posted at 10:22 am on January 24, 2006 by Gia Fly
30 Agreeing with #19
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.
posted at 10:53 am on January 24, 2006 by Mark Priestap
Discussion Closed
New comments are not being accepted, but you are welcome to explore what people said before we closed the door.
Got something to say?
Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.
Create a new account or sign in below if you’d like to leave a comment.
Subscribe to this article's comments: RSS (what’s this?)
21 Glossary page
No problem. You have
<abbr href=“glossary.htm#css” title=“Cascading Style Sheets”>css</abbr> and <abbr href=“glossary.htm#html” title=“HyperText Markup Language”>HTML</abbr>, where the destination of the two links is different – what comes after the # does count.
posted at 02:07 pm on January 18, 2006 by Stephen Down