WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG 2 draft and abbreviations

for

From: Philip Kiff
Date: Aug 24, 2007 8:50AM

Jukka K. Korpela wrote on Fri 24 August:
> On Fri, 24 Aug 2007, Philip Kiff wrote:
>> 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)".
>
> Why would that matter? WCAG 2 is just a draft, which may never turn
> into a specification, still less a widely approved one. Even if it
> does, it should serve accessibility work, not vice versa.

Well, to be fair, the subject line of the thread is "WCAG 2 draft and
abbreviations". I understood that the original poster sought advice with
respect to interpretations of the WCAG 2 draft and the best practice
techniques.


> The bottom line is that <acronym> has no useful defined semantics but
> may understandably be taken in the dictionary sense. It is
> semantically _worse_ than <span>, which by definition lacks all
> defined semantics.
[...]
> Just because they keep the misguided and misguiding idea even in the
> new draft doesn't mean we should use such markup.
[...]
> It was a wrong idea and does not
> become any better by time.
[...]
> If you just want the tooltip effect, then <span> is superior to
> <acronym>.

Your position seems to be that in the best practice scenario, nothing should
be used? And then at the next step down from the best practice, neither
<abbr> nor <acronym> should be used: since <span> would be better? And then
at the third step down, if developers decide to use one of those elements,
then they should use <abbr> only, or <abbr> for abbreviations and <acronym>
only for pronounceable initialisms?

I can see the argument for the latter two points, but I disagree with the
notion that using nothing is better than abbr/acronym or that <span> is a
better tag to use. In general, it seems to me that the best practice
recommendation is to use <abbr> instead of <acronym>, as you suggest (if you
insist on using at least one of those elements). However, I think that the
best practice recommendation should be modified based on one's target
audience when necessary.

With respect to the choice of whether to use <acronym> or <abbr>, I think
you are making far too much of the "semantic" difference between <abbr> and
<acronym>, and the ways that those semantic differences may have an effect
on a site visitor/screen reader user, now and in the future. My point is
that this semantic difference will have NO effect on a current screen reader
user or visual browser user and so it is not really that important to
uphold. This is especially true in the case of a site where 65% of their
target audience are using IE6.

The idea of "semantic" HTML does not mean that HTML code has all of a sudden
become a language full of absolute dictionary meanings and definitions, it
is still just code: the "semantic" part depends on human interpretation and
there continue to be arguments of the supposed "semantic" meanings of
various elements: ul vs. ol (A-Z lists?), h1 vs. h2 (subheadings, site
titles?), dl vs. table (what is a "definition list"?), address vs. p (which
parts should be marked address, and how?), etc. The differences in
interpretation of <abbr> and <acronym> are just one more in a list of
"semantic" ambiguities in X/HTML, and in my opinion those differences are
relatively unimportant when it comes right down to it. It is much more
important to serve up your pages with code that works in the most popular
browser used by your site visitors.

I am somewhat sympathetic to the argument that it would be better to use
nothing at all and ignore the <acronym> and <abbr> elements entirely;
however, I think you have only managed to construct (here and elsewhere) a
weak case for that position, and I am not yet convinced by your arguments
along those lines. In particular, I find the following counterarguments
more convincing:
- some users find the tooltip acronym/abbr expansions useful, particularly
in the case of long documents with many acronyms whose expansions are only
given once in the text (this is based on anecdotal evidence)
- no research has been done to demonstrate that such coding is confusing or
causes problems for anyone
- acronym and abbr are part of both the HTML and XHTML specs, and abbr at
any rate does not appear to be going away
- the dotted underline below abbr/acronym has become a common "standard" in
modern browsers, so it is becoming less and less strange to users
- advanced users of screen readers or visual browsers can customize their
browsers to display acronym/abbr however they want, whereas there is no way
for them to customize the display of <span> without a standard in place to
identify which spans are used to expand acronyms/abbreviations
- web page content is not simply print content transferred to the web: the
web is a different medium that offers additional ways of conveying content,
and just because a document and its abbreviations and acronyms should be
completely understandable without *requiring* acronym/abbr tags, does not
mean that those tags cannot enrich a document in an electronic medium
- in the future, a JavaScript or some other script could be developed to
read the DOM and produce a pop-up list of acronyms and abbreviations on the
fly, whereas such a list could not be produced if you used span
- in the future, if <acronym> is entirely eliminated, then there will no
longer be any semantic distinction in coding between acronym and abbr, so
the question of the use of acronym instead of abbr will become an even more
"academic" question that it is currently

Phil.