All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
On this page:
Rationale
The intent of this checkpoint is to ensure that, wherever possible, content can be operated through a keyboard or keyboard interface. When content can be operated through a keyboard or alternate keyboard, it is operable by people with no vision (who cannot use devices such as mice that require eye-hand coordination) as well as by people who must use alternate keyboards or input devices that act as keyboard emulators. Keyboard emulators include speech input software, sip and puff software, on-screen keyboards, scanning software and a variety of assistive technologies and alternate keyboards. Individuals with low vision also may have trouble tracking a pointer and find use of software much easier (or only possible) if they can control it from the keyboard.
The phrase "except where the task requires analog, time-dependent input" is included to separate those things that cannot reasonably be controlled from a keyboard. For example, a watercolor application where the stroke is defined by the movement and speed of movement and/or pressure is not something that can be controlled from a keyboard. Also, use of MouseKeys would not satisfy this success criterion because it is not a keyboard equivalent to the application; it is a mouse equivalent (i.e. it looks like a mouse to the application).
Rich Internet applications
Rich Internet application keyboard navigation should behave like desktop application keyboard navigation. For example, keyboard users tab to Windows Explorer and then use the arrow keys to navigate to elements in the tree. WAI-ARIA provides support for arrow key navigation of complex widgets such as menus, trees and grids via the tabindex attribute or activedescendant property. For more information on how to implement arrow key navigation, see the Keyboard and Structural Navigation section of the WAI-ARIA Best Practices and Key-navigable custom JavaScript widgets.
Note that the WAI-ARIA activedescendant property is only supported in Firefox 3.0 or higher and JAWS 10 or higher at this time.
Required development techniques
Compliance with this checkpoint requires all of the following techniques be met. These techniques are defined in the WCAG 2.0 Level A Success Criterion for Guideline 2.1.1 (link resides outside of ibm.com).
1. Keyboard control: Ensure keyboard control of all functionality
2. Event handlers: Providing keyboard-triggered event handlers
Examples for HTML developers
1. Keyboard control: Ensure keyboard control of all functionality
To comply with this technique, example one must be implemented. Example two must be implemented for rich Internet widgets (e.g., trees, menus, etc.).
Example 1
Ensure keyboard control by using HTML form controls and links.
User agents provide the keyboard operation of HTML form controls and links, therefore, whenever possible standard HTML form controls and link elements should be used. Form controls and link elements can be tabbed to, and standard controls can be operated without additional development effort.
Example 2
Rich Internet widget keyboard navigation should behave like desktop widget keyboard navigation. For example, keyboard users tab to Windows Explorer and then use the arrow keys to navigate to elements in the tree. WAI-ARIA provides support for arrow key navigation of complex widgets such as menus, trees and grids via the tabindex attribute or activedescendant (link resides outside of ibm.com) property. For more information on how to implement arrow key navigation, see the Keyboard and Structural Navigation section of the WAI-ARIA Best Practices (link resides outside of ibm.com) and Key-navigable custom JavaScript widgets (link resides outside of ibm.com).
Note that the WAI-ARIA activedescendant (link resides outside of ibm.com) property is only supported in Firefox 3.0 or higher and JAWS 10 or higher at this time.
2. Event handlers: Providing keyboard-triggered event handlers
There are no specific techniques for HTML.
Examples for Script developers
For techniques that have no technology-specific examples, refer to the HTML example section for guidance.
1. Keyboard control: Ensure keyboard control of all functionality
There are no specific techniques for Script developers.
2. Event handlers: Providing keyboard-triggered event handlers
To comply with this technique, all of the following examples must be implemented
Example 3
Provide keyboard-triggered event handlers.
All event handlers executed by non-keyboard UI events (such as a mouse click) should also be triggered by a keyboard-based event. For example, if you use the onmouseover event handlers, you should also add a redundant onclick mechanism, so that a keyboard only user can perform the action.
Another example is if you use a drag and drop feature, the user must be given the opportunity to perform the same actions using either cut and paste or another keyboard based approach.
For additional information, refer to WCAG 2.0 examples for providing keyboard triggered event handlers (link resides outside of ibm.com)
Examples for Dojo developers
1. Keyboard control: Ensure keyboard control of all functionality
There are no specific techniques for Dojo developers.
2. Event handlers: Providing keyboard-triggered event handlers
To comply with this technique, all of the following examples must be implemented
Example 4
Provide keyboard-triggered event handlers for Dojo
- The Dojo Dijit widgets are accessible. If the widgets are modified or extended, it is the developer's responsibility to ensure that they remain accessible. For example, when a Dijit widget is placed on a page it is accessed by tabbing. However, once it receives focus, the widget itself is navigated with arrow keys. The default arrow key navigation should not be modified when extending or modifying a widget
- The Dijit Tooltip widget is similar to the HTML title attribute but more flexible. The Tooltip widget supports rendering arbitrary HTML and timing control. In order to activate a tooltip with the keyboard, a trigger element must be capable of receiving focus. If a trigger element isn't focusable by default, include a tabindex=0 attribute to put the element in the page tab order.
- The Dojo TabContainer widget illustrates how arrow keys are used to navigate among tabs. When a user tabs to the following TabContainer, the active tab (tab two) receives focus, and the left and right arrow keys are used to navigate the tabs.
The Dojo Book provides keyboard navigation documentation for each of the Dijit widgets. For more information on how to include Dojo in your application, see Dojo Accessibility Overview.
Examples for Adobe® Flash® developers
For techniques that have no technology-specific examples, refer to the HTML example section for guidance.
1. Ensure keyboard control of all functionality
There are no specific techniques for Flash developers.
2. Event handlers: Providing keyboard-triggered event handlers
To comply with this technique, all of the following examples must be implemented
Example 5
Provide keyboard-triggered event handlers in Flash.
- Ensure that all elements in the Flash movie are device-independent. Device-independence allows people to navigate the movie using a mouse, keyboard-only, voice-input, or other assistive technologies. For elements that cannot be made device-independent, provide an equivalent function that is device-independent.
- All controls that can be manipulated via the mouse must also be accessible via the keyboard. The Adobe Flash Player facilitates keyboard access on its own by automatically making mouse defined events accessible via the keyboard. In addition, add keyboard shortcuts to facilitate keyboard access in complex applications.
More information can be found on the Adobe Flash Accessibility Design Guidelines website for Keyboard Access (link resides outside of ibm.com).
Examples for IBM® Lotus® Domino® developers
For techniques that have no technology-specific examples, refer to the HTML example section for guidance.
1. Keyboard control: Ensure keyboard control of all functionality
There are no specific techniques for Domino developers.
2. Event handlers: Providing keyboard-triggered event handlers
To comply with this technique, all of the following examples must be implemented
Example 6
Provide keyboard-triggered event handlers for Domino.
The objective of this technique is to permit individuals who rely on a keyboard or keyboard interface to access the functionality of the content. To do this, make sure that all of the events used in scripts or other interactive controls on the page are associated with a keyboard-based event or provide redundant keyboard-based mechanisms to accomplish the functionality provided by other device-specific functions.
Domino supports JavaScript event handlers on a form, subform, page, field, action, button or action hotspot using the Programmers Pane. Some event handler actions are not accessible via a keyboard. Care should be taken to provide alternate methods especially when using event handlers such as onMouseOver, onMouseOut, and so on. The onClick event handler is keyboard accessible.
The following JavaScript events must have alternatives for keyboard accessibility:
- onDblClick - There is no alternate event that provides keyboard accessibility. Use of onDblClick must be avoided.
- onMouseMove - There is no alternate event that provides keyboard accessibility. Use of onMouseMove must be avoided.
- onMouseDown - OnKeyDown may be used to provide keyboard accessibility.
- onMouseOut - OnBlur may be used to provide keyboard accessibility.
- onMouseOver - OnFocus may be used to provide keyboard accessibility.
- onMouseUp - OnKeyUp may be used to provide keyboard accessibility.
Recommended development techniques
The techniques above are required; the following techniques are recommended to enhance accessibility:
See WCAG 2.0 Additional Techniques (Advisory) for 2.1.1 (link resides outside of ibm.com) for a list of techniques and examples.
Required test techniques
The following test tools and techniques are required to test this checkpoint.
Test tools:
Install the following tools to test this checkpoint
Required accessibility verification test techniques:
Use the following accessibility verification test (AVT) techniques to validate the Web content. It is recommended that these tests be performed in order.
| Action | Result | |
|---|---|---|
|
Test the Web site with a Web syntax analyzer to verify the compliance criteria as follows:
The tool does not identify any of the following
|
Pass:
|
| Action | Result | |
|---|---|---|
|
Verify the compliance criteria for this technique as follows.
|
Pass:
|
| Action | Result | |
|---|---|---|
|
Verify the following compliance criteria with a screen reader.
For detailed instructions on how to test this checkpoint with a screen reader follow the 'Screen reader accessibility verification tests for Web checklist 5.1' document. |
Pass:
|
®2009 IBM Corporation
Last updated August 31, 2009.
W3C Recommendation 11 December 2008: http://www.w3.org/TR/WCAG20/ (link resides outside of ibm.com)
Copyright 1994-2009 W3C (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University), All Rights Reserved.