Re: Section 4.3

Denis, could you please include the plain text if possible?

Anyway:

To be able to configure alternate devices for input and output is of
Priority 1.

In the area of input devices, under many operating systems, where standard
operating systems procedures are used (and I believe that this is already
a P1 requirement) reconfiguration or emulation of the keyboard is the most
effective way to apply a different input device. If the keyboard can
control all functions of the browser, then it is an ideal method in MOST
but not necessarily ALL circumstances. (For example, EIA, a browser for
the Learning Disabled uses a touchscreen, which I think emulates a mouse.)
For those cases where keyboard input is used, it seems to me that the
ability to reconfigure the keyboard is priority 1. Again, in many systems
this can be done at the system level rather than within the particular
product. Providing documentation of the configuration, and of how to alter
it, is also P1.

I am uncertain whether rendering the availability of an Accesskey is P2 or
in fact P3. I do however feel that should it be done, then a mechanism
must be provided for rendering the required input technique, rather than
the access key as given. For example, where an element has accesskey="c"
and the User Agent uses that to bind control-f3 to the element, the
rendering must specify control-f3 not "c". (Obvious really, but it is nice
to have these things made explicit. This is particularly important in the
case of User Agents which restrict the number of available keys.

Charles

Received on Tuesday, 9 March 1999 15:46:33 UTC