WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG 2 draft and abbreviations

for

From: Philip Kiff
Date: Aug 23, 2007 10:10PM

>> Peter Weil wrote on Thursday, May 31, 2007 10:46 AM:
>>> I know this topic has been discussed previously on this list,
>>> but I still have some quesitons about it.
>>> [snip]

> smithj7 wrote on 22 August 2007 19:26 EDT:
>> Great question.
>>
>> We have been discussing the same issue at our Florida standards
>> meetings.
>> [snip]

Readers following this thread may want to consult the original set of
replies to Peter Weil's question back at the end of May:
http://webaim.org/discussion/mail_archive.php?sort_by=1&;id=10656#10656

Also, my impression from that original thread was that each of the possible
solutions mentioned by smithj7 would be acceptable under WCAG2, including
the one that "proposes tagging the first instance after each header (h1
through h6)". See especially the comments by Loretta Guarino Reid in that
earlier thread for further clarification of the WCAG 2 intent.


Jukka K. Korpela wrote on 23 August 2007:
> smithj7 wrote on 22 August 2007 19:26 EDT:
>> Note: I used the acroynm because about 65 percent of our customers
>> are using IE6.
>
> Does that justify giving semantically wrong information? What happens
> if some day some speech browser utilizes <acronym> markup and
> pronounces, say, <acronym>IEP</acronym> as a pronounceable word
> (eye-ep? yep? who knows?) as it really _should_, if the word
> "acronym" is taken in its meaning in cultivated literary English?

As noted in the original thread at the end of May, there is legitimate
disagreement amongst "cultivated" English language users over the exact
meaning of the word "acronym" and of the precise distinction between an
abbreviation and an acronym.

In the current WCAG 2 draft, <abbr> is identified as the general case: "It
is always appropriate to use the abbr element for any abbreviation,
including acronyms and initialisms. When using HTML 4.01, XHTML 1.0 or XHTML
1.1, initialisms and acronyms may be marked up using the acronym element.
XHTML 2.0 proposes eliminating the acronym element in favor of the more
general abbr element."
See Techniques for WCAG 2.0 - H28: Providing definitions for abbreviations
by using the abbr and acronym elements - Applies to WCAG 3.14
(Abbreviations):
http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#H28

I personally do not think that there is any danger of speech browsers/screen
readers EVER selectively deciding to attempt to pronounce things tagged as
<acronym> and not pronounce things tagged as <abbr>. It is far more likely
that such browsers will develop vocabularies of common
acronyms/abbreviations that they can consult in order to decide how to
pronounce such words, regardless of whether they are coded one way or
another. This is especially true since it appears that the acronym tag is
actually on its way out in XHTML 2 and since abbr is now supported by IE7.

If 65 percent of smithj7's users are still using IE6, then I would argue
that yes, it does justify the use of <acronym> instead of <abbr>. Indeed
for a number of years now some people have resorted to only using <acronym>
for all acronyms, initialisms, and abbreviations due to the desire to
compensate for the failures of various popular MSIE versions. In "semantic"
terms, there is real disagreement about what the "semantic" difference is.
And in practical terms, there are no differences in the way any past or
current screen reader handles <acronym> vs. <abbr>, so there is no "real
world" difference, and the use of <acronym> in place of <abbr> will
certainly not have any effect on "accessibility" in the current or near
future. Several years further into the future a simple find/replace script
will be able to upgrade all the code to abbr if it becomes necessary, but
for now, I think the use of acronym is fully justified in smithj7's case
because of the target customer base. There is nothing less accessible than
code that doesn't work in your browser.

Phil.