- From: Gregory J. Rosmaita <unagi69@concentric.net>
- Date: Wed, 18 Aug 1999 17:18:47 -0400
- 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 UTC