Understanding SC 2.1.2: No Keyboard Trap (Level A)
In Brief
- Goal
- Keyboard users don't get stuck.
- What to do
- Ensure users always know how to navigate away from components.
- Why it's important
- People who rely on the keyboard often have no other means to navigate.
Success Criterion (SC)
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.
Note
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. See Conformance Requirement 5: Non-Interference.
Intent
The intent of this success criterion is to ensure that that content does not “trap” the keyboard focus within subsections of content on a web page or app. It is common to restrict the focus to a specific dialog or popover. It can also occur if content is rendered using plug-ins or when content is embedded.
As long as the user knows how to leave a subsection of content (and “untrap” the focus), a web page can restrict the focus to a subsection of the content. In some cases, temporarily restricting the focus to a specific component is useful to help users understand where they are on the page and what interactions are possible. It also prevents the focus from being obscured, for example behind a dialog.
The keyboard focus is not considered as trapped when the user can navigate away from a UI component using the unmodified tab or arrow keys or when another “standard exit method” exists. What is a “standard exist method” depends on the user’s hardware and software. A press of the ESC key is such a “standard exit method”. When the press of the hardware back button on certain mobile operating systems “untraps” the keyboard focus is also sufficient. In addition, some screen readers have other ways, like swipe gestures, that result in a pressed ESC key.
Benefits
- People who rely on a keyboard or keyboard interface to use the Web including people who are blind and people with physical disabilities.
Examples
- A modal dialog box
- A web application brings up a dialog box. At the bottom of the dialog are two buttons, Cancel and OK. When the dialog has been opened, focus is trapped within the dialog; tabbing from the last control in the dialog takes focus to the first control in the dialog. The dialog is dismissed by activating the Cancel button, the OK button, or the ESC key.
- A calendar widget
- A calendar widget allows users to add, remove or update items in their calendar using the keyboard. The controls in the widget are part of the tab order within the Web page, allowing users to tab through the controls in the widget as well as to any links or controls that follow.
- A puzzle applet
- Once a user tabs into an applet, further tabs and other keystrokes are handled by the applet. Instructions describing the keystroke used to exit the applet are provided prior to the applet as well as within the applet itself.
Techniques
Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this Success Criterion. A technique may go beyond the minimum requirement of the criterion. There may be other ways of meeting the criterion not covered by these techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.
Sufficient Techniques
Failures
The following are common mistakes that are considered failures of this Success Criterion by the WCAG Working Group.
Key Terms
- keyboard interface
interface used by software to obtain keystroke input
Note 1
A keyboard interface allows users to provide keystroke input to programs even if the native technology does not contain a keyboard.
Note 2
Operation of the application (or parts of the application) through a keyboard-operated mouse emulator, such as MouseKeys, does not qualify as operation through a keyboard interface because operation of the program is through its pointing device interface, not through its keyboard interface.
Test Rules
The following are Test Rules for certain aspects of this Success Criterion. It is not necessary to use these particular Test Rules to check for conformance with WCAG, but they are defined and approved test methods. For information on using Test Rules, see Understanding Test Rules for WCAG Success Criteria.