W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 1999

the importance of acronyms to accessiblity

From: Gregory J. Rosmaita <unagi69@concentric.net>
Date: Wed, 18 Aug 1999 17:18:47 -0400
Message-Id: <4.1.19990818164850.0097d640@pop3.concentric.net>
To: w3c-wai-gl@w3.org, User Agent Guidelines Emailing List <w3c-wai-ua@w3.org>
aloha!

i am forwarded the following message to both the WCAG and UA lists, in
order to communicate what i feel is an extremely important issue, which i
believe has hitherto received short shrift...  

the exchange from which the following message is extracted began with a
proposal to the AU list for re-wording the introduction to Guideline 4 by
Charles McCathieNevile, which is archived at:
<http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0099.html>

in a reply, archived at:
<http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0100.html>
Jim Thatcher  asked:

quote:
>Please, Charles,  tell me why -
>
>Generating accessibility content, including ... expansion for acronyms... is
>one of the most fundamental requirements of accessible content.
>
>I believe acronym expansion is irrelevant for access.
unquote

and, whilst Charles issued his own reply, archived at:
<http://lists.w3.org/Archives/Public/w3c-wai-au/1999JulSep/0101.html>

i felt compelled to address the issue of the importance of ACRONYMs to
accessibility, and upon further discussion of the issue during the 18
August 1999 AU teleconference, i decided that the issue was important
enough to bring up with the GL and UA working groups--to whom i should have
CCed my post in the first place...  my apologies to anyone who has already
perused this thread...

--- FORWARDED MESSAGE ---
Date: Tue, 17 Aug 1999 13:49:35 -0400
To: thatch@us.ibm.com
From: "Gregory J. Rosmaita" <unagi69@concentric.net>
Cc: Authoring Tools Guidelines List <w3c-wai-au@w3.org>
:
:
:
Subject: Re: acronyms

aloha, thatch!

i'm not charles, nor do i play him on TV, but that being said, let me take a
whack at answering your question...

there's an old saying that quote one man's poison is another man's food
unquote, and nowhere is that old saw more applicable than when discussing that
amorphous concept called accessibility....as i have oft declaimed in the past,
attempting to define the term accessibility is not only an essay in futility;
it is the reddest of herrings...  what the WAI is combating is inaccessibility
-- therefore, it is our task, as active participants in the WAI, to ensure that
existing barriers are removed and to safeguard against the erection of new
barriers...

so, what does that have to do with the expansion of acronyms?  simply stated,
there are a multitude of reasons why one would want an AU tool (at the very
least via its internal documentation and examples provided in its internal
help) to encourage authors to explicitly associate a text-string with ACRONYMs:

1. expansion of acronyms can greatly enhance the experience of an individual
with certain types of learning disabilities and dyslexia -- especially persons
who are not using any sort of adaptive technology to supplement their browsing
experience

2. when abbreviations and acronyms are not identified, they are often
indecipherable when converted into braille

3. for screen-reader users, such as myself, the expansion of acronyms an
incredible boon to my productivity and the quality of my online life in general
-- for example, if i query a search engine for the string quote ADA unquote,
when the search engine returns the hit list, i'd like to know which sites deal
with the Americans with Disabilities Act and which with the American Dental
Association...     or, if i am checking the MicroTalk site for information on
the ASAP screen-reader, i'd certainly want to be able to aurally distinguish
between the acronym that comprises the name of the screen reader and the
commonly used acronym ASAP -- otherwise, i might mistake the phrase: "you'll
receive ASAP ASAP" as merely another screen-reader slash synthesizer stutter...

when you are crawling the web with speech (and there is still no more apt
metaphor for aurally traversing today's web) or feeling your way around
cyberspace with a refreshable braille display, not wasting your time following
false leads can spell (pardon the pun) the difference between finishing a
homework or work assignment on schedule and drowning in a sea of unstructured
information....  if the AU tool doesn't encourage authors to insert an ACRONYM
value, how, then, am i to distinguish between two very different uses of the
same acronym?

DISCLAIMER: optimally, if the AU tools used to create the pages searched for in
the first example listed in point 3 are designed intelligently, they will
prompt the authors for such basic META data as "keywords" and "description",
which would be one (potential) means of alleviating the problem outlined
above.  END DISCLAIMER

optimally, i would like to "see" acronym expansion controlled by both the UA
and the AT -- the former should let me choose whether or not to expand
acronyms, whilst the latter (and i would hope that HPR falls into the latter
classification, at least in this instance) would provide me with an exceptions
dictionary, not unlike those used in word processors (or, for that matter, in
some screen-readers), so that i could control whether or not certain acronyms
are expanded, and even customize them, so that instead of hearing:
        N A A C P
i would hear
        en double-eh cee pee

and, whilst i am well aware of the fact that one can already set
application-specific and universal dictionary entries to control the
enunciation of acronyms with most screen-readers, there are, as i indicated
above, a great many acronyms that have more than one meaning, and reliance on
such a gross mechanism to control the expansion of acronyms is clearly
insufficient...

the expansion of ACRONYMs on a user-configurable schedule is an issue which
must be addressed by both the AU and the UA WGs...  to those whose gut reaction
is to dismiss the above-listed reasons as quote mere conveniences unquote
rather than accessibility aids, i ask them to disconnect both mouse and monitor
from their workstation for at least a month, before characterizing ACRONYM
expansion (and a host of other proposed accessibility enhancements) as
conveniences, rather than necessities...

and, if that line of reasoning doesn't convince you, try this on for size: 
there are those (and i am most definitely NOT amongst their number) who will
vociferously argue that every damn graphic that one places on one's web site
should be ALT texted, even if it is purely decorative...  could one not argue
that the text that is contained in the ACRONYM (and, for that matter, the ABBR)
as quote alternative text unquote?  syntactically, contextually, and
semiotically,both ACRONYM and ABBR fulfill the same function as ALT text, which
leads me to wonder why their use rates only a P3 in the WCAGL, although i do
endorse the extremely lucid explanation of why one should use the ACRONYM and
ABBR elements contained in the WCAGL's introduction to Guideline 4

gregory.
--------------------------------------------------------
He that lives on Hope, dies farting
     -- Benjamin Franklin, Poor Richard's Almanack, 1763
--------------------------------------------------------
Gregory J. Rosmaita <oedipus@hicom.net>
   President, WebMaster, & Minister of Propaganda, 
        VICUG NYC <http://www.hicom.net/~oedipus/vicug/>
--------------------------------------------------------
Received on Wednesday, 18 August 1999 17:14:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:00 GMT