Definition for WCAG 2.0 success criterion 2.1.2
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.
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
The intent of this Success Criterion is to ensure that that content does not "trap" keyboard focus within subsections of content on a Web page.
There may be times when the functionality of the Web page restricts the focus to a subsection of the content - for instance, when the user opens a modal dialog, focus should remain within the dialog. However, in order to pass this criterion, there must be a way for a keyboard user to leave that state and "untrap" the focus - in the case of modal dialogs, providing a keyboard-operable "Close" control and/or closing the dialog when the ESC key is pressed.
Beyond situations where incorrect JavaScript was used (for example, to inappropriately "catch" keyboard events without consideration for TAB / SHIFT+TAB), a common example of where keyboard traps can happen is when part of the page's content is rendered by plug-ins. Plug-ins are user agents in their own right that render content inside the user agent host window and respond to all user actions that takes place while the plug-in has the focus. If the plug-in does not provide a keyboard mechanism to return focus to the parent document, keyboard users may become trapped in the plug-in content.
Assistive technologies such as screen readers are generally controlled through keyboard shortcuts. For this reason, some of the keyboard handling may be different when a keyboard user also uses assistive technologies. For this reason, this criterion must be tested both without and with assistive technologies running.
Note: for success criteria involving keyboard testing, ensure that your browser/OS is set to allow for full keyboard navigation. In macOS in particular, go to System Preferences > Keyboard > Shortcuts and ensure that the "Full Keyboard Access" option is set to "All controls".
Note: if the page contains no elements that receive keyboard focus (either because there are no interactive components, or because the page already fails 2.1.1 Keyboard (level A)), this criterion is marked as not applicable.
Testing success criterion 2.1.2
Input into spreadsheet
- Fail
- Tabbing through the content, the user becomes trapped and cannot tab out of the content, to continue through the rest of the content.
- Pass
- The keyboard can be used to tab though all content, and focus does not get trapped.
How to test
Test with the keyboard only to ensure that users are not trapped in content that can only be exited using a mouse or pointing device.
- Using TAB / SHIFT+TAB, navigate through the entirety of the page.
- If the page features alerts, modal dialogs, overlays, dropdown menus or similar interactive components, trigger these (e.g. to open a modal dialog) and verify that TAB / SHIFT+TAB still works, and that there is some mechanism (e.g. an actual "Close" control that can be focused/activated with the keyboard, or using ESC) to move away from the component.
Next, turn on your assistive technology (e.g. JAWS, NVDA, VoiceOver, TalkBack) and repeat the above testing steps to ensure that keyboard controls still function when AT is present, and that no keyboard traps are present.