- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Fri, 11 May 2001 11:42:44 -0500
- To: w3c-wai-ua@w3.org, w3c-wai-ua-request@w3.org
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