Make all functionality available from a keyboard
When a functionality can be achieved using only the keyboard, other input devices can be used. But, if you use only a mouse or a speech input, assistive technologies will find it difficult to operate it.
Obviously, you can use another input devices to complement the keyboard, and even you are encouraged to do it, but don’t forget that every feature must be operable by a keyboard input.
Criterion 2.1.1 Keyboard
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. (Level A)
- The exception is about the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.
- This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.
How to. Mandatory techniques
- Ensure keyboard control by using HTML form controls and links
- Provide keyboard-triggered event handlers using both keyboard and other device-specific functions, making actions keyboard accessible by using the onclick event of anchors and buttons, or using redundant keyboard and mouse event handlers
Additional, Advisory Techniques
- Use XHTML role, state, and value attributes if repurposing static elements as interactive user interface components and add keyboard-accessible actions to static HTML elements
- Provide keyboard shortcuts to important links and form controls
- Use unique letter combinations to begin each item of a list
- Choose the most abstract event handler
- Use the onactivate event
- Avoid use of common user-agent keyboard commands for other purposes
Common Failures
- using only pointing-device-specific event handlers (including gesture) for a function
- using script to remove focus when focus is received
- using scripting events to emulate links in a way that is not programmatically determinable
Criterion 2.1.2 No Keyboard Trap
If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. (Level A)
- Since any content that does not meet this success criterion can interfere with a user’s ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion.
How to. Mandatory techniques
- Ensure that users are not trapped in content
Common Failures
- Combining multiple content formats in a way that traps users inside one format type
Criterion 2.1.3 Keyboard (No Exception)
All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. (Level AAA)
How to. Mandatory techniques
This is the same as Success Criterion 2.1.1, but no exceptions are allowed. Just follow techniques for it. If there is a requirement for analog, time-dependent input, then it is not possible to meet this Criterion.