Re: Raw minutes from 10 May 2001 UAWG teleconference

I'd also like to know in detail which components of the interface we are
discussing.  Much of the a o l interface has little to do with web
connectivity as I understand it, but more to do with their generally
closed network.  Still, General software guidelines apply and there is
more than msaa at issue here.

----- Original Message -----
From: "Jon Gunderson" <jongund@uiuc.edu>
To: "Richard Schwerdtfeger" <schwer@us.ibm.com>
Cc: <w3c-wai-ua@w3.org>; "Tim Lacy" <timla@microsoft.com>
Sent: Friday, May 11, 2001 1:32 PM
Subject: Re: Raw minutes from 10 May 2001 UAWG teleconference


Rich,
Apparently the special APIs were jointly developed in cooperation with
an
AT developer, but I think your arguments are still valid.  We don't want
to
promote the use of special APIs for different AT developers.  I have
asked
Scott to contact Tim Lacy at Microsoft to discuss the issues on why MSAA
could not have been used to solve the problem.

Jon


At 11:42 AM 5/11/2001 -0500, you wrote:
>I would like to respond to Scott Trotman's comment regarding checkpoint
6.6
>from Issue 471 on the third last call issue list.
>
>Scott's comment is as follows:
>
> >Checkpoint 6.6:  I understand the need for standard APIs and
documented
>APIs
> >for non-standard implementations.  But because of the way some ATs
work,
> >custom code has had to be written by both AOL and AT developers.  The
same
>is
> >true for other software companies.  I believe a priority one for the
> >implementation of a user agent should be "make it work".  Priority
two
>should
> >be "make it work using standards".  I can go into much greater detail
>about
> >this if it draws a discussion.
>
>Having worked the number of years I have in this business, I can tell
you
>that the use of non-standard APIs does not work.
>My response is not meant as a personal attack, however I expect this
issue
>to be raised a fair bit so I will be strong in my response to make sure
>that the issue is put to bed ... for good.
>
>First, the team writing a new set of APIs has no experience as to what
>makes something accessible and what does not.
>
>Second, the likelihood that an assistive technology (AT) will work with
>your new API set is is highly unlikely. This means people with
disabilities
>have to wait until an AT does. Without an AT solution all the API's in
the
>world do not make your solution accessible. A point in fact is that
>Netscape 6.0 is still inaccessible today is in part due to the fact
that it
>has not made use of a standard set of API's. I am sure that on the
Windows
>platform Netscape is being heavily pressed to support MSAA on Windows
since
>screen readers do not know how to work with it. In Netscape's defense
they
>are working to make it accessible.
>
>Third, the API and its implementation need to be tested using an AT or
they
>do not work. The Java Accessibility API has been proven to work because
not
>only did it get architected by experts (primarily IBM and Sun) but it
was
>also tested using an assistive technology (Self Voicing Kit for Java).
>
>Fourth, we require support of the DOM because is is reviewed by the WAI
>Protocols and Formats group who are a team of experts in the the
>accessibility field. As a PF member and a person who wrote requirements
for
>the PF to the DOM working group we try to make the DOM engineered to
work
>with ATs.
>
>Fifth, in order to make a W3C specification you need to prove
>implementability. This is nearly impossible with a new home grown API.
In
>the case of the DOM API we use Home Page Reader and our Web Access
Gateway
>project as a proof of implementability. We are not going to do this for
>some new legacy API a corporation has been working on for years and
wishes
>to retrofit to try and meet an accessibility standard.
>
>Sixth, the issue of cost and performance is key to an AT developer. It
>costs developer time and AT performance to try and support some new API
>each application want to export.
>
>Seventh, is time to adoption. It took, years before AT's started to use
>MSAA. This was due to instability, performance, and other reasons. It
took
>years from the time we started the Java Accessibility API until it was
>reliable and full functioned enough to use. To do this, IBM, Microsoft,
and
>Sun had to spend a lot of money and expert resources to make this
happen.
>In the case of the DOM, W3C accessibility expert members needed to do
the
>same.
>
>These are the reasons that you write to standards.
>
>Bottom line: We use standards to make applications readily and reliably
>accessible and usable in the shortest period of time so that the user
of
>your application can be gainfully employed and that they may enjoy the
>quality of life that you the application developer has. The longer this
>period is the more we place this person at a disadvantage.
>
>Rich Schwerdtfeger
>Senior Technical Staff Member
>IBM Accessibility Center
>Research Division
>EMail/web: schwer@us.ibm.com
>
>"Two roads diverged in a wood, and I -
>I took the one less traveled by, and that has made all the
difference.",
>Frost

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
MC-574
College of Applied Life Studies
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL  61820

Voice: (217) 244-5870
Fax: (217) 333-0248

E-mail: jongund@uiuc.edu

WWW: http://www.staff.uiuc.edu/~jongund
WWW: http://www.w3.org/wai/ua

Received on Saturday, 12 May 2001 09:42:35 UTC