W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2000

Re: SUMMARY expands on CAPTION or TITLE _as required_

From: Aaron Leventhal <aaronl@chorus.net>
Date: Wed, 27 Dec 2000 16:13:51 +0000
Message-ID: <3A4A153F.8090305@chorus.net>
To: w3c-wai-ig@w3.org
CC: mozilla-accessibility@mozilla.org
Recently AOL/Netscape have decided to start looking very
carefully at their accessibility story, and what needs to
get done on the road to excellent compliance with W3C
accessibility guidelines and standards. The bad news is that
there's a long way to go; the good news is that education
and planning have begun, and they are interested in making
this a community process.

Netscape 6 relies on the same rendering engine for user
interface layout as it does for content like HTML. The user
interface is designed with an XML dialect called XUL. There
are interesting consequences to this. For one thing, the
user interface supports the DOM, CSS and is scriptable.
However, it does not use native platform widgets, and thus
gets nothing in the way of accessibility for free.

We see two ways of providing support to accessibility tools
that need information about our user interface and the
content window. 1. Provide access to our internal W3C
complaint DOM to the accessibility aid, as specified in
guideline 5 of UAAG. 2. Provide support for
platform-specific accessibility standards, such as MSAA and
the upcoming Gnome Accessibility standard.

Unfortunately for us, being cross-platform makes everything
more difficult. For example, we use our own cross platform
component model, called XPCOM, which does not yet support
access by external "out-of-process" software applications.
Developing such support is non-trivial.

Most of today's accessibility solutions are Windows based,
and a number of them support MSAA. This indicates that
supporting MSAA needs to be strongly considered. However, we
do not want to be caught in a situation where we need to
support a different accessibility standard on every platform
we develop for. Is it possible to have a cross platform
accessibility standard that satisfies everyone? What is the
possibility of extending DOM to support the special features
of accessibility API's, rather than asking cross-platform
application vendors to support a new standard on each
platform? It seems important to support all of the features
an accessibility API would normally provide. Would this be
stretching the DOM standard too far?

Perhaps now is a good time to answer this question, before
the growth of open source creates a resurgence in
cross-platform application development. Will vendors be
asked to support more than two standards. such as 1)
externalized DOM, 2) MSAA, 3) Gnome Accessibility, 4) KDE
Accessibility and 5) possibly other standards? Or can we
extend DOM and re-use it as a single cross-platform
accessibility standard that both application vendors and
accessibility solutions providers can adhere to?

I hope this stimulates a useful discussion. Also,
please join our mailing list by sending an
email to mozilla-accessibility-request@mozilla.org
(subject=subscribe).

Aaron Leventhal
Received on Wednesday, 27 December 2000 17:11:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:13:51 GMT