Re: the importance of acronyms to accessiblity

Gregory,

I don't hear what you meaning abbreviation expansion is an accessibility issue.
For me, for example, when you typed ADA I thought you were talking about
American's for Democratic Action.  But I, as most people, pick up the intention
from context. I can find nothing in what you said that makes ABBR and ACRONYM
priority one accessibility issues. Priorit three with no problem.

Below you asserted, quote expansion of acronyms can greatly enhance the
experience of an individual ...  endquote. How can you possibly claim that. No
agents support it (do they??). When I see an acronym or abbreviation, I
sometimes wonder what it is. It would be nice to bring up the context menu for
the item and get its intended expansion. But greatly enhance the experience ...
no.

I assume when you mention braille, you are talking about braille 2 translation,
because a braille 1 translation is identical to the problem I have when I can
see the letters.  But what is the braille interface to decide wether to present
the expansion or the abbreviation.  Some would predict that the interference
with smooth reading is not worth the occasional mystery produced by an ACRONYM.

How, Gregory, do you know that expansion of acronyms will be quote an incredible
boon to my productivity and the quality of my online life in general endquote.
Matter of fact, how could you possibly say that? Are you joking?

Jim Thatcher
IBM Special Needs Systems
www.ibm.com/sns
thatch@us.ibm.com
(512)838-0432


"Gregory J. Rosmaita" <unagi69@concentric.net> on 08/18/99 04:18:47 PM

To:   w3c-wai-gl@w3.org, User Agent Guidelines Emailing List <w3c-wai-ua@w3.org>
cc:
Subject:  the importance of acronyms to accessiblity





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 18:50:25 UTC