Discuss: The Accessibility Hat Trick: Getting Abbreviations Right

by Colin Lieberman

1 JAWS and title attributes

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”.

posted at 07:39 am on January 17, 2006 by Brian LePore

2 Links to glossary - no way back?

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).

posted at 07:45 am on January 17, 2006 by Matthew Pennell

3 Redundant Class?

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.

posted at 10:18 am on January 17, 2006 by Tom Clancy

4 What's the hurry?

“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) <acronym> 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.

posted at 10:23 am on January 17, 2006 by Chris Hunt

5 Untitled

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.

posted at 11:11 am on January 17, 2006 by Robert Wellock

6 Shooting for AAA is fine...

…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.”

posted at 11:57 am on January 17, 2006 by patrick lauke

7 Untitled

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:
<dfn title=“see glossary”>root-mean-square
statistic</dfn>

posted at 01:36 pm on January 17, 2006 by Gerben de Keijzer

8 A Way Back

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.

posted at 02:48 pm on January 17, 2006 by Colin Lieberman

9 I Disagree

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.

posted at 05:38 pm on January 17, 2006 by Adam Burmister

10

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.

ACRONYM may have seemed like a good idea (as a guide to the pronunciation of initialisms), but in practice it’s been a confusing disaster. All acronyms are abbreviations(†), but not all abbreviations are acronyms; using the acronym element to mark up all abbreviations is semantically unsound. There’s also the subjective element regarding which initialisms are spelled out in speech and which are pronounced as words and therefore fall into the subset “acronym” — ask a group of geeks how to pronounce “SQL,” “ASP,” and “FAQ” and you’ll see what I’m talking about.

It is, therefore, clear that ACRONYM will not meet all our abbreviation needs (unless the W3C decides to redefine the term, in which case I wash my hands of the whole thing), so we need to find a way to make ABBR work anyway. When both logic and the working draft of the next spec agree that it’s time to make a change, I think it’s worth taking said change into consideration when you sit down to define your approach to accessibility.

As for the geekiness comment, this is an article about abbreviation markup and AAA-level compliance. This is about as geeky as it gets. :)

(†) We can argue this point, but the OED is on my side and I will cut you.

posted at 07:02 pm on January 17, 2006 by Erin Kissane