Re: Some comments on conformance levels in UA guidelines draft

Hi Peter,

First off I would like to state that I wrote the OSM for Screen Reader/2 so
I understand what you are saying.

However, what I am also saying is that there many screen readers with
differenct OSM architectures. Furthermore, these OSM's become more
convoluted as new technology, like the DOM, is made available to reduce the
dependency on GUI drawing to OSM reverse engineered architectures. Even
more important is the fact that these screen reader vendors feel that the
way their specific OSM design is a key differentiator from competitors.
Some of these like Screen Reader/2 contained things like menu hierarchies.

Tying engineered hooks back into these a non-standard OSM architecture is a
tall order and not one that should be required of user agent developers.
Also, there are platforms like UNIX where there are no screen reader
products that make use of an OSM.

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.b.l.meijer@philips.com on 12/02/99 04:20:16 PM

To:   w3c-wai-ua@w3.org
cc:   Richard Schwerdtfeger/Austin/IBM@IBMUS
Subject:  Re: Some comments on conformance levels in UA guidelines draft




Rich Schwerdtfeger wrote

> Whose OSM? OSM's are screen reader vendor specific and are
> not resident on any platform other than OS/2 and Windows.

This is in part why I had written

> Additional work will be needed to forge this into a solid and
> open standard, particularly if we want this as independent from
> any particular operating system as possible

All operating systems with a GUI have an off-screen model of
some sort: there is no way to manage a GUI without it. The
model may just not be available for third-party developers
of assistive technology to allow for creating a wedge that
implements alternative accessible I/O - as needed for screen
readers, for instance.

The implementation of, and set of hooks into, off-screen
models is indeed operating system specific, but the basic
visual object structure of a GUI is extremely similar across
many platforms (Microsoft Windows, X-Windows on UNIX systems,
Mac OS, OS/2, Java OS and so on): you nearly always find menus,
icons, window borders (often with maximize, minimize and close
gadgets and a title bar), buttons, edit boxes, scroll bars and
so forth, soon covering the majority of controls needed to use
an application effectively. To make my point as a sighted
person: I have never used OS/2, but I'm confident that I can
use it within five minutes for basic work.

Now let's consider basic menus for some further illustration.

It really is not so hard to specify that an off-screen model
should contain a copy of the menu hierarchy of the "standard"
menus of all active application instances, plus the textual
content of menu items, in a way that third-party assistive
technology can access that information. The "reference" screen
reader for any operating system will for accessibility compliance
be required to present all of this information in an accessible
form, allowing a blind user to navigate, for any application,
its menu hierarchy and select and activate one particular menu
item, while the application in turn will be required to create
its own menus as "standard" menus for accessibility compliance.
(Before sprinkling known exceptions over me: I do not claim to
be exhaustive or exact here, I'm merely trying to convey the
basic ideas, which may be hard enough.) I think it should not
be too difficult to spell out what "standard" means for each of
the dozen or so operating systems that we may wish to consider,
but yes, it does involve additional work.

The main issue really is to specify *that* all "standard" menus
must be made accessible by a screen reader in order to meet the
UA conformance requirements. (Thus not just the menus of the
screen reader itself!) Then the general application developer
will know beforehand that simply using "standard" menus is OK
and meets the conformance requirements, so that the use of this
application in combination with any screen reader that meets
the conformance requirements will *guarantee* accessibility
(of menus in this oversimplified example).

Right now the conformance requirements in the UA guidelines
do not seem to fully and clearly address the accessibility
of a combination of screen reader with generic application,
while that seems the only economic way for making many of
the best applications accessible to blind people.

It would be rather worrisome if the UA guidelines would
implicitly favour "self-contained" accessibility packages
by specifying compliance ratings that cannot be properly
applied to combinations of screen readers with generic
applications (such as mainstream browsers used by the
sighted), while the current trend seems to be rather that
blind people increasingly prefer using just that.

This is, again, why I think a compliance rating based on
the current UA guidelines is not in order. Unintentionally,
it could appear biased and selective w.r.t. accessibility
practices and efforts, by providing a compliance rating
only for products that include accessibility provisions
"natively".

The UA guidelines are at their current stage excellent as
an informal checklist, which is highly useful and a major
achievement, but I suggest that the UA guidelines are not
ready for labelling products through a compliance rating.

Best wishes,

Peter Meijer


The vOICe Internet Sonification Browser
http://ourworld.compuserve.com/homepages/Peter_Meijer/eyebrows.htm

Received on Wednesday, 8 December 1999 14:11:39 UTC