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: Wed, 1 Dec 1999 19:00:50 +0100
To: <w3c-wai-ua@w3.org>
Cc: <ij@w3.org>
Message-ID: <0056890007178454000002L942*@MHS>
[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 13:01:51 UTC

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