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

Re: comments on guidelines

From: Ian Jacobs <ij@w3.org>
Date: Sat, 04 Dec 1999 12:38:22 -0500
Message-ID: <3849518E.C8C951AF@w3.org>
To: "Leonard R. Kasday" <kasday@acm.org>
CC: Denis Anson <danson@miseri.edu>, w3c-wai-ua@w3.org
"Leonard R. Kasday" wrote:

> 
> Or, more to the point,  what if a company has a little pocket sized voice
> browser, with a tiny display, that would be fine for the majority of blind
> surfers... provided some care was taken to avoid any remaining dependence
> on the visual display.  But suppose the product had no external interface
> for any device, let alone a standard API.  If we tell that company right up
> front "there's no way this can be even be a level A user agent" and cause
> them to give up going the few extra steps that would make it a low cost,
> convenient device for blind users who can use speech?

This is exactly the type of device we are *not* catering to in these
Guidelines. That particular device would be extremely useful
for many users (Can you get me one??), but it's not the general
purpose device the guidelines are designed to address.
 
> As I look at the guidelines I've got to admit that as it reads you've got
> to accommodate all disabilities to get a level A.   But that I think is a
> problem with the conformance level definition.
> 
> This could be addressed with "qualified" conformance levels, where you
> qualify what disabilities it applies to.
> 
> So this generates a new issue: a suggestion of "qualified" or "limited"
> conformance levels, e.g.
> 
> A/visual that satisfies all priority 1 that impact people who are blind
> A/hearing  ...etc.

The Working Group has discussed the "user profile" approach
to conformance for these Guidelines and decided not to pursue it.
For background information on conformance approaches/proposals
considered by the WG, please refer to [1]. In particular, refer to
Al's initial proposal for a conformance provision based
on user profile [2].

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0433.html
[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/1998OctDec/0344.html
 
> By the way, I do not support such ratings for web content accessibility
> guildelines.  Web pages should be accessible to all people, period.
> 
> Also, I am only proposing this for UA's like specialized devices, where
> full API use and interfacing may be a real burden.  I am not supporting it
> for e.g. general PC programs.  General programs should also be accessible
> to all people.

That's the intended audience for this document. Future versions, or
additional documents intended for software in combination or specialized
tools would be very useful.
 
> However, user equipment that satisfies a particular disability can serve a
> practical need and I wouldn't want to discourage such equipment from being
> designed and being able to boast some sort of conformance rating.

Though a difficult decision to exclude (de facto) assistive technologies
from the conformance umbrella, the WG reached consensus on this issue,
as documented by the Chair in [3]. The resolution states:

   The User Agent Guidelines conformance clause will not 
   distinguish between classes of users agents.

Vendors of any type of software may claim conformance, but the
checkpoints
are geared at desktop graphical browsers and other general purpose
tools. Unfortunately, but by consensus necessary for the timely
completion
of this version of the Guidelines, this will probably prevent many
assistive technologies from being able to claim conformance.

 - Ian

[3] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0447.html

> 
> At 08:41 AM 12/3/99 -0500, Denis Anson wrote:
> 
> > >
> > > LRK: I think this is overly restrictive if the UA has accessibility
> > > built-in.  For example, a browser with built in speech output of all text
> > > on the screen.  In this case it is not absolutely necessary to give
> > > standard operating system access to the text, so I would suggest
> > > downgrading to Priority 2 or 3 (depending on how important it is to have
> > > Braille output).  This is a real possibility for pocket sized wireless web
> > > acccess devices, for which speech output is more practical than a tiny
> > > screen, especially when driving.
> >
> >But in this case, the *standard* APIs for the system would be different
> >(or non-existent), wouldn't they?
> >
> >There is a tendency to assume that those who can't read the screen will
> >automatically be able to hear the screen.  That simply isn't true.
> >Refreshable Braille may be the only access mode for a deaf-blind person.
> >The reason that the browser should expose the content through a standard API
> >is so that the user can use whatever access method is their standard, and
> >not have to limit themselves to the method that the author of the UA thought
> >was appropriate.
> >Denis Anson
> >College Misericordia
> >301 Lake St.
> >Dallas, PA 18612
> >
> 
> -------
> Leonard R. Kasday, Ph.D.
> Institute on Disabilities/UAP, and
> Department of Electrical Engineering
> Temple University
> 423 Ritter Annex, Philadelphia, PA 19122
> 
> kasday@acm.org
> http://astro.temple.edu/~kasday
> 
> (215) 204-2247 (voice)
> (800) 750-7428 (TTY)

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel/Fax:                     +1 212 684-1814
Cell:                        +1 917 450-8783
Received on Saturday, 4 December 1999 12:38:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:49:34 GMT