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

Re: Some comments on conformance levels in UA guidelines draft

From: <peter.b.l.meijer@philips.com>
Date: Thu, 2 Dec 1999 23:20:16 +0100
To: <w3c-wai-ua@w3.org>
Cc: <schwer@us.ibm.com>
Message-ID: <0056890007202431000002L912*@MHS>
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

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
Received on Thursday, 2 December 1999 17:20:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:24 UTC