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

RE: Section 4.3

From: Denis Anson <danson@miseri.edu>
Date: Wed, 10 Mar 1999 10:37:27 -0500
To: "Charles McCathieNevile" <charles@w3.org>
Cc: <w3c-wai-ua@w3.org>
Message-ID: <NCBBJFEKMOPIHFHNBHMMOEKLCDAA.danson@miseri.edu>
Guideline 4.3 Support accessible keyboard input
Not every user is able to navigate the web via a pointing device such as a
mouse.  The environment in which the user is operating may not support a
mouse.  Because of a physical or sensory limitation, the individual may not
be able to control a pointing device.  In these cases, some users may rely
on keyboard commands to control the user agent.  These commands may be
created using the physical keyboard, or may be generated via third party
assistive technology.  The user agent should provide full functionality via
the character based input as well via a point and click interface.
For those user agents that support keyboard input, the input methods must be
accessible. Some users require single-key access, others require that keys
activated in combination be physically close together, while others require
that they be spaced physically far apart. Configurability is vital to
accessible keyboard input.
The more apparent the keyboard commands are to all users, the more likely it
is that new users with disabilities will find them and use them.
[Checkpoint 4.3.1] Allow the user to configure keyboard access to user agent
functionalities. Configuration includes the ability to specify single
keystroke commands as well as commands that require keystroke combinations.
[Priority 2]
Because of the diversity of physical needs of users, there are no "right"
keyboard commands.  A user with limited mobility may not be able to
accurately press keys that are far apart on the keyboard.  Another user,
with limited motor control, may not be able to accurately produce commands
that are close together.  Because of the variety of needs, the keyboard
commands used to access user agent functionality should be configurable for
the user through an accessible, and understandable process.
[Checkpoint 4.3.2] Ensure that user can find out about all keyboard bindings
(e.g., through menus). [Priority 2]
Keyboard commands that are hidden from the user are of little utility.
There should be multiple avenues to information related to keyboard
bindings.  Some suggested methods of making this information available
include:
* Make all keyboard equivalents visible on pull down menus.
* The on-line help for each feature that offers keyboard control (all of
them) should also describe the keyboard shortcuts for that feature, and the
behavior available via the keyboard.
* On-line help should include a section on keyboard access that describes
the keyboard controls within the product.  This section should be organized
logically by function, rather than by alphabetical order.

[Checkpoint 4.3.3] Provide a mechanism to render the presence of a keyboard
binding for an active element. [Priority 2]
As noted previously, keyboard commands that are not apparent are of little
utility.  When a document element has a keyboard binding (via accesskey),
the user agent should render the keyboard binding along with the fact of its
existence.  The method of providing such rendering should be configurable by
the user.  For example, for access keys for links, underlinging the active
character will not generally be useful, since most links are rendered as
underlined text.  Some possible approaches to rendering access keys are:
* Render the active character of the element in an alternative color.  Note,
however, that such rendering may not be visible to a user with
color-blindness.
* Render the active character in a font that contrasts with the font of the
balance of the element.  Note, however, that such rendering may not be
visible to users of non-visual access technology.
* Render the active character with alternative text decoration for the
active element.  Note, however, that such rendering may not be visible to
users of non-visual access technology.
* Render the active character with an alternative voice pitch.  Note,
however, that such rendering will not be accessible to those who are using a
non-spoken interface.


Denis Anson, MS, OTR
Assistant Professor
Computer Access Specialist
College Misericordia
301 Lake Street
Dallas, PA 18612

RESNA
The International Organization of Assistive Technology Professionals

Member since 1989



-----Original Message-----
From: Charles McCathieNevile [mailto:charles@w3.org]
Sent: Tuesday, March 09, 1999 3:46 PM
To: Denis Anson
Cc: w3c-wai-ua@w3.org
Subject: Re: Section 4.3


Denis, could you please include the plain text if possible?
Received on Wednesday, 10 March 1999 10:36:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:22 UTC