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 Friday, 11 May 2001 13:32:07 UTC