W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2000

Re: About ABBR

From: Gregory J. Rosmaita <unagi69@concentric.net>
Date: Fri, 18 Feb 2000 15:55:07 -0500
Message-Id: <4.2.2.20000218153959.00ac6100@pop3.concentric.net>
To: thatch@us.ibm.com
Cc: WAI Interest Group Emailing List <w3c-wai-ig@w3.org>
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 15:45:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:13:48 GMT