Re: About ABBR

quote same argument that has traditionally kept ALT
from being routinely deployed endquote. It is not the same
argument.

Jim Thatcher
IBM Accessibility Center
www.ibm.com/sns
HPR Quick Help: http://www.austin.ibm.com/sns/quickreplace.html
(512)838-0432


"Gregory J. Rosmaita" <unagi69@concentric.net> on 02/18/2000 02:55:07 PM

To:   James Thatcher/Austin/IBM@IBMUS
cc:   WAI Interest Group Emailing List <w3c-wai-ig@w3.org>
Subject:  Re: About ABBR




aloha, thatch!

as someone who has designed, constructed, and maintained web sites for
educational, non-profit, and for-profit entities, i couldn't disagree
more...  what is the extra expense entailed in adding ABBR or ACRONYM to
page content?  this is the same argument that has traditionally kept ALT
from being routinely deployed, despite the fact that it is a required
attribute of IMG in HTML 4.0/4.01

your caution about being selective in what we ask for from content
developers because of cost simply doesn't wash...  what we are actually
doing is two-fold -- 1) asking content developers to design and implement
with accessibility in mind, and 2) to compensate for the shortcomings of
the existing technology upon which they are umbilically reliant, in
particular, the well-documented shortcomings of authoring tools...

that is where the true expense lies -- in evaluation and repair, not in
education and implementation...  what do most web content providers learn
when they take courses on web design/construction?  even at the most
prestigious of educational institutions, they very rarely learn the grammar
and syntax, they almost never learn the why behind the how, but are merely
given an expensive introduction to a particular authoring tool's
interface...

my argument isn't the only argument for implementing the accessibility
features that PF has worked so diligently to get integrated into W3C
promulgated markup languages, but it is one aspect of the broader solution
-- endowing the greatest possible number of individuals with equivalent
read AND write access to the web...

gregory.

thatch wrote:
>Gregory, your position, though understandable is untenable. Web site
>accessibility does cost something. When we go to content developers to ask
>that they include accessibility features we are asking that they learn
>more, that they do more, that their product cost more. We have to explain
>and demonstrate what they get for additional effort and cost. Providing
>stimulous for future user agent design will not make the cut.
>
>Jim Thatcher
>IBM Accessibility Center
>www.ibm.com/sns
>HPR Quick Help: http://www.austin.ibm.com/sns/quickreplace.html
>(512)838-0432
>
>
>"Gregory J. Rosmaita" <unagi69@concentric.net> on 02/17/2000 05:19:12 PM
>
>To:   Phill Jenkins/Austin/IBM@IBMUS
>cc:   WAI Interest Group Emailing List <w3c-wai-ig@w3.org>
>Subject:  Re: About ABBR
>
>aloha, phil!
>
>while i appreciate your quote taking the developer's practical view on
>this.unquote, determining whether or not to use ABBR (or recommend its
use)
>based solely on current UA implementation is the wrong approach...  new
>features of HTML 4.0/4.01 need to be stressed by authoring tools and in
>authoring forums precisely in order to force the hand of UA developers to
>implement them..  it's a classic chicken and egg conundrum -- or, to put
it
>even more obliquely, if an ABBR is defined on a page and no UA supports
>it's expansion, does it make a noise?
>
>yes, passing the validation test is but the first step, but when do we
stop
>saying quote wait until user agents support x, y, and z before you add x,
>y, and z to your pages unquote, and begin to build the momentum that will
>force developers into supporting the accessibility features which the PF
>working group has worked long and hard to get included into W3C-generated
>markup languages?
>
>no, i don't know if it will work, since no user agents or screen-readers
>currently support switching languages in mid-stream, but unless those of
us
>who are page authors begin to implement accessibility-oriented features
>such as ABBR, ACRONYM, and SUMMARY (for tables), what impetus do
developers
>have to support these features?
>
>moreover, it isn't just a case of switching language in mid-stream -- the
>use of CSS pseudo-elements (as outlined in the UAAG techniques document)
to
>demarcate an inline natural language change will benefit a wide range of
>users, and not merely users with disabilities...
>
>gregory.
>
>Phil wrote:
> >How do you know if either will work if no user agents support it?  I
> >understand passing a validator is helpful to determine the approach, but
> >until someone implements it, who knows if it will work?
> >
> >I don't know of any product that supports either changing languages
> >mid-stream nor picking up the title attribute on the ABBR element.  And,
>in
> >this simple case it doesn't make a difference anyway does it?  LEADER
> >pronounced in English or Spanish is about the same. I hope somewhere
else
> >on the page it is explained in plain Spanish that LEADER is the
> >abbreviation for "Programa Europeo de Desarrollo Rural"
> >
> >I'm
> >
> >Regards,
> >Phill Jenkins

--------------------------------------------------------------------
ABSURDITY, n.  A statement or belief manifestly inconsistent with
one's own opinion.       -- Ambrose Bierce, _The Devils' Dictionary_
--------------------------------------------------------------------
Gregory J. Rosmaita      <unagi69@concentric.net>
Camera Obscura           <http://www.hicom.net/~oedipus/index.html>
VICUG NYC                <http://www.hicom.net/~oedipus/vicug/>
Read 'Em & Speak         <http://www.hicom.net/~oedipus/books/>
--------------------------------------------------------------------

Received on Friday, 18 February 2000 23:28:59 UTC