E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 1 (In chronological order)

From: Jukka Korpela
Date: Wed, Dec 11 2002 1:32AM
Subject: RE: Acronyms
No previous message | No next message

Rachel wrote:

> I know that the authors will be using lots of acronyms
> in their content. I don?t think the authors will have
> the capability or patience to add a <acronym
> title="spelled out version of the acronym goes here">
> tag to every acronym they use.

We've discussed the acronym and abbreviation problem
quite a lot, and it's fairly confusing. Besides,
<acronym> and <abbr> markup is not that important
in practice at present or in the near future; browser
support is quite "varying", to put it obscurely.

The really important thing to all users, and especially
to people with learning or memory disabilities or simply
insufficient information, is that all abbreviations,
acronyms, and special notations be explained as simply as
possibly, in document content proper. There are various
options (non-exclusively) to do this:
- explain each abbreviation etc. upon its first occurrence
- put a list or table of explanations at the start
- put it at the end or a separate page and link to it
at the start of the document
- make an occurrence of an abbreviation etc. a link to
its definition.

> The first time you mention a name on the page, spell
> it out and follow it with the acronym in parentheses.
> Example:
>
> Environmental Protection Agency (EPA)

That's good; an example of the first option above.
In many cases, it's quite sufficient. It is debatable
whether "EPA" should be made a link to EPA's Web page.
It surely depends. Lots of links could confuse people.
In a separate list of abbrevations, there's no reason
not to make them links, but in running texts, it's different.
In this case, for example, a Google search for EPA gives
the right page as the first hit. (In the general case, though,
the availability of the full name is important for finding
the right information, on the Web or elsewhere.)

> OPTIONAL:
>
> Every time you write an acronym, write <acronym>
> before it and </acronym> after it. Example:
> Environmental Protection Agency
> (<acronym>EPA</acronym>)

In principle, that's correct, if "EPA" is to be treated
as a pronounceable word (of acronymic origin). But it's
not of much practical use at present, I'm afraid.

In principle, it could also be beneficial to use a title
attribute with the expansion:
Environmental Protection Agency
(<acronym title="Environmental Protection Agency">EPA</acronym>)
The reason is that for _programmatic_ processing, such as for
a hypothetical (?) browser that automatically constructs
lists of all acronyms and abbreviations on a page, to be
optionally presented to the user, would need the expansion
that way (though some heuristics might make it guess right,
in simple cases, what part of normal document text is in fact
an expansion of an acronym).

Moreover, further occurrences of the acronym could carry that
markup. On a browser that shows <acronym> titles as "tooltips"
or otherwise makes them available to the user, this would
help a person who keeps forgetting what each TLA means.
(TLA = Three-Letter Acronym.) On the other hand, the WAI
recommendations tell us to use the <acronym> or <abbr>
markup for first occurrences - though it can hardly be
read as _prohibiting_ repeated use of the markup. And in
practice, I don't think even those browsers that somehow
support <acronym> or <abbr> really treat them the way
postulated in that WAI recommendation. (They would need
symbol tables etc.)

Using a "redundant" title attribute as in
Environmental Protection Agency
(<acronym title="Environmental Protection Agency">EPA</acronym>)
may have a somewhat undesired side effect. Browsers that support
<acronym> typically show the acronym with a dotted underline,
if the <acronym> element has a title attribute. This is nice
for letting the user know that there's some kind of an
explanation available. But it's confusing in a context
where the explanation just repeats something that is
already said in the text proper. My (partial) remedy to that
is to use CSS to suppress the underlining in such cases, e.g.
using class="redund" in the <acronym> element and
acronym.redund { border: none; }
in a style sheet. Actually I also use
acronym { border-color: gray; }
since even in cases where the indication is useful, it tends
to be a bit too distracting by browser defaults.

> (The purpose of this option is to assist screen
> readers in pronouncing the acronym correctly. In the
> site CSS file, we'll define the style of the acronym
> tag as { speak: spell-out })

That's fine in principle. But I don't think there's
any program yet that supports this.

--
Jukka Korpela, senior adviser
TIEKE Finnish Information Society Development Centre
http://www.tieke.fi/
Diffuse Business Guide to Web Accessibility and Design for All:
http://www.diffuse.org/accessibility.html


----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/