WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: abbreviations


From: Denis Boudreau
Date: May 26, 2010 3:54PM

Hey, me again.

On 2010-05-26, at 4:28 PM, John Foliot wrote:

> Denis Boudreau wrote:
>> Huh, I mean, an important part of an efficient approach to ensure
>> that some users with specific types of limitations have access
>> to content.
> Correct, which is why *not* using <abbr> simply because, in its default
> setting, JAWS (a commercial software package that runs on one operating
> system) does not voice out the value string is a wrong reason for not
> using <abbr>. This setting can be changed in JAWS quite easily, but more
> importantly adding <abbr> when required also enhances accessibility for
> some *other* users who may not be using a screen reader.

But most Jaws users will never change this because they need the @alt support more than they need the @title's. I'm guessing the approach is similar with other screen readers, is it not?

So unless something drastically changes with time, this might always be a problem.

Screen readers developers make us choose between @alt and @title because otherwise, users risk getting the information twice from otherwise well-intentioned authors who don't realize both would be read aloud.

I don't really see that behaviour changing anytime soon.. :/

> Bottom line: use <abbr> when appropriate.

But who would benefit? What's the real incentive?

Screen reader users will not see it,
User agents do not seem to interpret it,
Mouseless users will not benefit from it.

Sure the HTML spec likes it, but what kind of real gains does that entail for users?

Maybe the spec got that part wrong. The idea is good, but in reality, authors make it impossible to implement.

We've seen that happen with other elements or attributes in the past (summary, longdesc, acceskey, etc.), so why not with <abbr> and <acronym> too?

Denis Boudreau