RE: comments on guidelines

>
> 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

Received on Friday, 3 December 1999 08:39:25 UTC