Re: Raw minutes from 10 May 2001 UAWG teleconference

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

Received on Friday, 11 May 2001 12:44:09 UTC