RE: comments on guidelines

Denis,

You're right that speech wouldn't be enough for a person who was blind and 
deaf, and that the need for Braille is often overlooked.

Still, what if there was a hypothetical browser that did voice output and 
had drivers for the popular softbraille displays.  Are we going to deny 
that product even an A rating?

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?

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.

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.

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.

Len



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)

Received on Friday, 3 December 1999 11:12:41 UTC