WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Acronym/Abbreviation best practice

for

From: Jared Smith
Date: Mar 13, 2009 9:05AM

On Fri, Mar 13, 2009 at 8:35 AM, Dan Conley wrote:
> Is there a reason not to, besides 'it takes a lot of work?'
> (find/replace, especially with regex, helps a lot in those
> circumstances)

Consider the WebAIM site where we use a lot of acronyms. It would, for
example, be quite annoying to hear "Asynchronous Javascript and XML"
for every instance of "AJAX". Now if screen readers were smart enough
to only expand it in the first instance or on demand, then it would be
less burdensome. You could also argue that the styling (typically a
dotted underline) of all acronyms impacts readability of text. If the
acronym is always expanded, the user may not even learn the acronym at
all.

For the record, we're in the process of removing acronym from all
relatively well-known acronyms (HTML, CSS, etc.) on our site. This
might not be appropriate for other sites, but for our site and our
audience, I think it makes sense. Less well-known acronyms (W3C, WCAG,
etc.) will be expanded in text in their first instance and then not
marked up with acronym. Very unknown and less commonly used acronyms
(SMIL, SAMI, etc.) will be expanded in text in the first instance and
marked up with <acronym> in all instances (or at least significant
instances - such as immediately after new headings). In short, my
thinking right now is to pretty much get rid of <acronym> on the site
except for the occasional unknown acronyms/abbreviations.

And yes, this will make it so we are never WCAG 2.0 AAA compliant. Meh.

Jared Smith
WebAIM