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.