- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Tue, 21 May 2002 15:08:37 -0500
- To: w3c-wai-ua@w3.org
Issue 529 refers to a proposal for a revised checkpoint 6.1/6.2 Checkoint. Checkpoint 6.2 proposes that any API can be used so long as it satisfies the content required by checkpoint 6.1 and that it be documented. I would like to propose that checkpoint 6.2 be modified as follows: 2. Otherwise, where W3C normative bindings do not exist that the W3C DOM API must be used and that the User Agent's document binding for it must be publicly documented so that it may be used by an assistive technology. My reasons for making this more stringent are as follows: - At IBM we consider the Web as a platform. It has its own accessibility infrastructure and sets of guidelines and is a framework on which to deliver applications/content independent of the target device. In the process of making Web accessible, the WAI working groups, and in particular the PF group, evaluate and produce accessibility guidelines to make the Web and all content delivered on it accessible. To ensure access to the Web we define changes to programmatic W3C API that must be platform neutral. The DOM is the W3C API that is being targeted to provide access to structured content. Without having control over its specification we could not have addressed the recent "events" API changes that we made to the DOM for the purposes of accessibility. - Recent accessiblity information targeted through XML, SVG, XFORMS, etc. accessibility done by the PF group can be addressed with the DOM WG to ensure that it can be accessed by an AT through a designated W3C API. The WAI has the ability to control the specification of the DOM API because it is a W3C specification. The W3C does not have the ability to control the information provided by a proprietary API. - Implementing the DOM does not preclude additional Accessibility API (such as MSAA) from being used but it does guarantee the core API set needed by the WAI working groups be provided for. - The W3C is one of the few places where all the platform vendors (Sun, IBM, Microsoft, etc.) get together and agree on standards. A standard API agreed on by the W3C then comes more easiliy adopted and supported in the future. - Having a standard W3C accessibility API for Web content makes it easier to develop cross-platform AT solutions even in the absence of normative bindings. - Having a standard W3C accessibility API for Web content makes it easier to develop multi-user agent, single-platform AT solutions (Adobe, IE, Netscape, Opera, Amaya on Windows) even in the absence of normative bindings. - We have plenty of implentation experience with using a platform-specific DOM binding in IE with IBM's Home Page Reader and Freedom Scientific's JAWS. I understand fully that in the case of C++ we are at the mercy of the operating system implementation. By itself, C++ does not address cross-process marshalling. It does not address in-process multi-threaded access. This is why platform bindings need different C++ bindings to support these features such as through the use of COM, XPCOM, or Corba. This does not preclude a platform documented C++ binding for the DOM. With a standard W3C API (that starts with the core DOM) we can build upon it to require DOM events notification, the CSS DOM API, a DOM Views API, etc. in the future. Many of the people on the call only have had to deal with Windows. At IBM we have to deal with Solaris, Linux, Windows, AIX, the Web, Java, etc. Having a single W3C DOM API that, in the case of C++, may require different platform documented bindings is essential. Rich 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 Tuesday, 21 May 2002 16:08:42 UTC