Re: Tenative meeting on the DOM with AT vendors for the User Agent Guidelines

Hi Peter,

I like your comments. Full keyboard access is required in the User Agent
Guidelines, so in this respect we are covered from a requirements
perspective.

In addition to the DOM effort, the PF group is working on addressing
semantics wrt XML. We are targetting the DOM as the conduit from which to
extract this information. I have also asked that an editorial team be set
up in the DOM WG to investigate an accessible web application architecture
derived from the DOM.

Your comment about stopping to rely in reverse engineering is well taken. I
spoke with Jim and he accurately stated that the reverse engineering
technology has served the disabled community well for a long time but that
he felt that an engineered approach was needed for the Web.

I do believe, in the long run, that AT vendors will welcome an engineered
solution because it will allow them to focus on real usability features and
not hacks. Jim mentioned that many of the vendors are communicating
directly with GUI components where possible as opposed to using the OSM. It
may also allow them to reduce development costs on legacy systems for
handling complaints and new hacks. It may also let them get into other
markets like pervasive rather than spending all their efforts on supporting
a single operating system.

Rich

Rich Schwerdtfeger
Lead Architect, IBM Special Needs Systems
EMail/web: schwer@us.ibm.com http://www.austin.ibm.com/sns/rich.htm

"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.",
Frost


Peter Korn <peter.korn@sun.com> on 01/31/2000 07:14:37 PM

To:   Charles McCathieNevile <charles@w3.org>
cc:   Richard Schwerdtfeger/Austin/IBM@IBMUS, James
      Thatcher/Austin/IBM@IBMUS, Jon Gunderson <jongund@ux1.cso.uiuc.edu>,
      mark novak <menovak@facstaff.wisc.edu>, w3c-wai-ua@w3.org
Subject:  Re: Tenative meeting on the DOM with AT vendors for the User
      Agent  Guidelines




Hi Charles,

Please pardon my soap-box...

> while I agree with you that an Off Screen Model is often not the best way
> to engineer a product, particularly for cross-platform protability, I
don't
> think there is an intrinsic reason why it is harmful. If a developer was
> working only on a single platform (and many do) and found that using an
OSM
> was more effective than tying to get through a bizarre API or an
> undocumented one, then it may be a better solution.

There is a significant issue with the OSM approach: responsibility for
problems in accessibility are almost never clear.  If one screen reader's
OSM
is able to capture information on the screen through some particularly
tricky
heuristics, then it is to the benefit of the users of that particular
screen
reader, but it may not work in other screen readers (to the detriment of
those
users).  Then the question becomes who should change -> the poorly behaved
application putting that information on the screen, or the OSMs of the
other
screen readers?

If there is a standard way for applications to describe their contents via
a
programming interface (API), then it is much eaiser to figure out what is
going wrong and fix it.  The API may be insufficiently expressive, the app
may
not be implementing the API properly, or the assistive technology may not
be
utilizing the API.  Those three things I claim are eaiser to test and
verify
than the finger-pointing we get via the OSM model.  When we have an API,
assistive technologies can always go beyond the API (as happens already
today), if the API or the application implementation(s) of the API do not
meet
their needs.

> I think a DOM which includes access to the chrome is a great benefit to
> accessibility, and using itis a very good way to meet the needs of
> users. However I am not sure that it is always a requirement.

Should we not require full keyboard access?  After all, the functionality
of
one screen reader - outSPOKEN for Macintosh - provides features like Find
that
make keyboard access less critical (especially since on the Macintosh there
isn't that much support in the OS for keyboard access to controls).  Also,
an
assistive technology could potentially assign their own keyboard access
mechanism on top of ill-behaved apps (just as screen readers build
information
in their OSMs that by rights should be directly exposed by applications).


I think going forward we need to require that applications provide *all* of
their semantic information directly via a clear and easy to use API to
assistive technologies.  Assistive technologies have a long, proud, and
painful history hacking around operating systems and applications so as to
provide their users with access.  The engineering staffs of these companies
have tremendous expertise in reverse engineering behavior, and these
techniques have provided tens of thousands of users with workable access
solutions and thereby employment and general access to information.  But it
is
time we stop relying on this expertise, and leaving users with a mish-mash
patchwork of access quality to applications that are supposedly complying
with
a new set of guidelines on how to be compatible with assistive
technologies.
We can do better than that, and require better than that, of the next
generation of applications.


Peter Korn
Sun Accessibility team

Received on Tuesday, 1 February 2000 11:14:03 UTC