Issue 529

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