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: Denis Anson <danson@miseri.edu>
Date: Wed, 1 Dec 1999 14:10:50 -0500
To: <peter.b.l.meijer@philips.com>, <w3c-wai-ua@w3.org>
Cc: <ij@w3.org>
I think that we can fix this issue.  (I've raised it myself on several
occasions.)  The key, I think, is that the user agent might not have to
provide screen reading natively, but it does have to provide a standard
interface to screen readers.  If a browser exposes the content to third
party assistive technology in a standard and documented way, then it could
be compliant.  If the information is not accessible, or must be "reverse
engineered" to access, then the browser is not compliant.

If we make our language focus on what a user agent must do in terms of
having methods of export, then it doesn't have to have native screen
reading, native expanded keyboard access, etc.  So long as there are
communication channels, it will be compliant.

Denis Anson, MS, OTR
Assistant Professor
College Misericordia
301 Lake St.
Dallas, PA 18612

Member since 1989:
RESNA: An International Association of Assistive Techology Professionals
Website: http://www.resna.org
ORLANDO, FL, JUNE 28 -- July 2, 2000

-----Original Message-----
From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On Behalf
Of peter.b.l.meijer@philips.com
Sent: Wednesday, December 01, 1999 1:01 PM
To: w3c-wai-ua@w3.org
Cc: ij@w3.org
Subject: Re: Some comments on conformance levels in UA guidelines draft

[Again, I implicitly refer only to access for blind users in the text below,
but we may generalize the issues later on to include other disabilities.]

Thank you very much, Ian, your comments indeed do clarify
some things to me, but at the same time begin to confuse me
to the extent that I may start asking silly questions about
what the main target audience is for these UA guidelines:
whether it is those involved in developing accessibility
layers (e.g. screen reader developers), or those involved
in general applications that may need to adhere to some
extra rules to match what screen reader technology can do,
or both groups. To cite a few sections from the guidelines:

> User Agent Accessibility Guidelines 1.0
> ...
> "User agents must satisfy natively all the applicable
>                           ^^^^^^^^         ^^^^^^^^^^
>          checkpoints for a chosen conformance level."

where applicable is further defined as

> If a user agent offers a functionality, it must ensure
> that all users have access to that functionality or an
> equivalent alternative.

and native support as

> A user agent supports a feature natively if it does not
> require another piece of software (e.g., plug-in or
> external program) for support.

and you add

> To avoid the dependencies you describe below (e.g., works
> with one screen reader but not with another), we decided
> that conformance would not include tools used in combination.

Consequently, according to these guidelines and your notes,
web browsers like Microsoft Internet Explorer and Netscape
are w.r.t. the current conformance requirements not accessible
user agents for blind people, because these user agents are
of no use to them without a combination with, for instance,
a screen reader (an external program). The same similarly
applies to my image sonification user agent.

If so, that indeed avoids the complicating dependencies that
I discussed, by excluding the vast majority of applications
that are in practice accessible to blind people, but only in
combination with a screen reader or equivalent third-party
assistive technology.

Yet the abstract of the guidelines begins with

> An accessible user agent allows users with disabilities to
> retrieve and view Web content or to enable access when used
> in conjunction with other software or hardware, called
> assistive technologies.

where assistive technologies include screen readers.

> These guidelines discuss the accessibility of the user
> agent as well as how the user agent communicates with
> assistive technologies such as screen readers, screen
> magnifiers, braille displays, and voice input software.

So now external programs like screen readers seem allowed,
and thus MSIE, Netscape, and my sonification browser would
appear accessible (give or take a few minor changes that may
still be needed to really meet all of those new checkpoints).

I'm lost here! I could force myself to consistently interpret
things by assuming that the conformance definition suddenly
adds the major burden of requiring full native support for
screen reading functionality, but it seems rather strange
that a tool that could quite well get a triple-A conformance
rating for blind users *if* a combination with a third-party
screen reader were allowed in the requirements, now drops to
a zero-A conformance rating. There will then be many fully
accessible user agents around that get a zero-A rating? Who
will care for this rating then if its scope is this narrow?

I'm sorry if I misinterpreted you, but when I get confused
here, others may share that same fate. I would have hoped
for a wide scope for the conformance requirements, although
that would indeed imply that some sort of reference screen
reader functionality must be defined to get around the
complicating dependencies that I discussed in my previous

What I would have strongly hoped for is that a minimum set
of functions is defined that the "reference screen reader"
can be assumed to perform. All screen reader developers will
then be motivated to provide at least this minimum functionality
(and probably more to make them stand out from the crowd),
such that they can brand their product as triple-A compliant
with the guidelines, while on the other side many developers
of (general) applications will be motivated to provide full
access under this minimum set, e.g., by using only standard
buttons, checkboxes and so on such that they can brand their
product too as triple-A compliant with the guidelines. The
blind user will then know that if he or she uses a triple-A
screen reader together with any triple-A general application,
that full accessibility is ensured. Moreover, the fact that
only one screen reader installation is required (the one
preferred by the blind user) helps to ensure a consistent
"look-and-feel" across applications. For instance, the blind
user will probably prefer having a single speech engine to
access most applications. In addition, this is by far the most
economical way of working, because few application developers
will want to take the major effort/cost of including a screen
reader to make their tool triple-A compliant, while screen
reader developers lack the expertise to develop the best-in-class
mathematics package, or browser, or whatever application you
may think of. We need a well-defined interface in the middle
to best combine the expertise of screen reader developers with
the expertise of application developers. Until this definition
has been worked out, it would seem best to drop (postpone) the
conformance rating altogether? The UA guidelines will then
indeed "just" be guidelines for the time being, but that will
be a good and useful start already. In my personal opinion, a
conformance rating is not ready for prime-time yet: it is
currently either too narrow in scope to be useful or it shows
too many interdependency pitfalls when it allows for tools
used in combination.

Best wishes,

Peter Meijer

The vOICe Internet Sonification Browser
Received on Wednesday, 1 December 1999 14:09:31 UTC

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