RE: ABBR vs. ACRONYM

Gregory, Kynn, Charles, et al....

I have tried to sit back and be patient,  but this thread has gone far
enough. You are discussing a Priority *3* checkpoint, and I cannot (read:
will not) believe that there are not more critical issues that we need to
come to consensus on.

This thread makes me feels as if I am in the faculty club of (***insert
favorite elite university****) sipping my favorite Port discussing how many
angels can dance on the head of a pin.

The WCAG are about providing equal access to information. If an acronym is
not understandable in its context, it is equally as inaccessible to
everybody. Why should we be any different?

If I was new to Web Access, and I subscribed to this list to get practical
tips on web accessibility, this thread would turn me off completely.
Admittedly, it does provide some intellectual fodder for us web access
junkies, but it also makes a mockery out of our mission.

Thanks,

dc

-------------------------------------------------------------------
David M. Clark
Director of Accessibility
halftheplanet.com
Email: dclark@halftheplanet.com  URL: http://www.halftheplanet.com
Boston Office: 617/859-3069 (phone/fax)

-----Original Message-----
From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org]On Behalf
Of Gregory J. Rosmaita
Sent: Tuesday, February 22, 2000 8:28 PM
To: pjenkins@us.ibm.com
Cc: WAI Interest Group Emailing List
Subject: RE: ABBR vs. ACRONYM

aloha, phil!

i'm extremely troubled when i hear representatives of developers say things
such as:

quote
If nothing does or nothing should happen with ABBR, then why mark it up?
unquote

the quote it isn't supported so why do it unquote approach is the very
mind-set that the WAI exists to change...  when you advocate ignoring any
markup which isn't currently supported by a quote mainstream unquote user
agent, you are throwing the baby out with the bathwater...

why should we forego using markup that isn't supported in mainstream user
agents?  by such logic, no one should bother using LONGDESC, SCOPE, AXIS,
and any of the other elements and attributes that are defined for HTML 4x,
but which are either supported spottily, incompletely, inconsistently, or
not at all...

your point about the application of stylesheets to demarcate (visually or
aurally) that (a) this is an abbreviation, (b) this is an acronym, and (c)
that an expansion is available, is, however, well taken, and is a
compelling argument against jettisoning one or the other...

one might --  based on a visual or aural stylesheet, or via the use of
inline pseudo-elements -- care to expand or not expand text enclosed in
either the ACRONYM or ABBR tags, or allow one's user agent or adaptive
technology to do so either by default or when queried, or to compile a list
of abbreviations and/or acronyms and their expansions, but in order to
perform (or have one's software) perform any one (or any combination) of
the actions listed above, one first needs to _know_ that expansions have
been defined for the document currently being rendered...

finally, what constitutes an abbreviation and what constitutes an acronym
_is_ germane to the discussion, as they are not only very different things,
but pose different sets of problems for different groups of users...  the
number of potential users affected by use of ACRONYM and ABBR is quite
large, as they not only enhance accessibility, but are aids to non-native
speakers of the natural language declared for the page being rendered, as
well as general usability aids...

gregory.

At 02:17 PM 2/22/00 -0600, Phil wrote:
>Emmanuelle wrote:
> >I believe that none of both should be eliminated. In Spanish the
distinction
> >between acronym and abbreviation is very clear. ...
> >
> >... in Internet Explorer when in a page there is an
> >identified acronym as such, if the pointer of the mouse is placed on him
its
> >definition it can be read, that which doesn't happen with the
abbreviations.
> >And this is logical because the abbreviations are of common use in a
> >language, ...
>
>PJ:
>If nothing does or nothing should happen with ABBR, then why mark it up?
>If the user agent should expand it [at the users request], just like
>ACRONYM, then why have both? Perhaps it doesn't matter if both are treated
>the same by being expanded, even thought to some they are different things.
>If your point is that they should be treated differently, then how?  If the
>difference is that one should be expanded and the other not, then we are
>back to my argument that it should not be marked-up. I don't know of any
>ELEMENTS that are treated the same, at least none that haven't been
>deprecated,  Many deprecated duplicate elements are still supported anyway,
>just no guarantees.
>
>Since user agent manufactures will maintain some backward compatibility and
>continue to handle both - who cares if we deprecate one?  We're not solving
>a problem by deprecating one or the other are we?
>
>I'm O.K. with having both even though they should / will be expanded the
>same by compliant browsers.
>
>What ABBR and ACRONYM - are - is not important in this context.  How they
>are specified to be treated is the important part.  I might want a list of
>them, I might want them expanded in different languages, I might want them
>highlighted per my style sheet, etc.  The user agent should let me do all
>these things to both of them.  Is there an argument that they should in
>fact be treated inherently different by the user agent?
>
>Regards,
>Phill Jenkins

--------------------------------------------------------
He that lives on Hope, dies farting
      -- Benjamin Franklin, Poor Richard's Almanack, 1763
--------------------------------------------------------
Gregory J. Rosmaita <unagi69@concentric.net>
    WebMaster and Minister of Propaganda, VICUG NYC
         <http://www.hicom.net/~oedipus/vicug/index.html>
--------------------------------------------------------

Received on Wednesday, 23 February 2000 09:32:14 UTC