WCAG (Level A) SC 2.1.2 No Keyboard Trap (W3.org)
Issue description
WCAG 2.1.2, “No Keyboard Trap” is a critical accessibility guideline that aims to prevent situations where keyboard-only users become stuck in a particular area of a web page. This is essential for people who rely on keyboards for navigation, including those with motor impairments who cannot use a mouse and individuals who use assistive technologies like screen readers.
Keyboard traps occur when a user can navigate to a component of the page using a keyboard (typically using the Tab key) but cannot move the focus away from that component using only the keyboard. This can happen with:
- Complex interactive widgets: Custom components or third-party widgets might trap focus within their internal elements, preventing users from tabbing out.
- Modal dialogs or pop-ups: If a modal dialog or pop-up doesn’t provide a clear keyboard mechanism to close it, users can become trapped inside.
- Incorrect use of
tabindex: Improper use of thetabindexattribute can create unexpected tab order and trap focus.
Consequences of keyboard traps
- Frustration and confusion: Users can become stuck and unable to proceed with their desired actions.
- Inability to complete tasks: Users might be unable to access certain content or features if they cannot escape the keyboard trap.
- Forced mouse use: Users might be forced to use a mouse to regain control, which is not possible for those who rely solely on keyboards.
Essentially, WCAG (Level A) SC 2.1.2 No Keyboard Trap ensures that users can navigate freely and predictably through the website using only the keyboard. It requires that if keyboard focus can be moved to a component, it can also be moved away using standard keyboard mechanisms (like the Tab, Shift+Tab, or arrow keys) or clear instructions are provided for alternative exit methods.
Related requirements
The following WCAG source criteria are often related to this as well. They can provide additional insights into specific challenges you may be encountering.
- WCAG (Level A) SC 2.1.1 Keyboard
- WCAG (Level AAA) SC 2.1.3 Keyboard (No Exception)
- WCAG (Level A) SC 2.1.4 Character Key Shortcuts
Who this issue impacts
Follow the links for additional information on user impairments:
Suggestions for remediation
Remediating WCAG 2.1.2, “No Keyboard Trap” involves ensuring that keyboard focus can always be moved away from any component it can be moved to, using standard keyboard mechanisms or clear instructions for alternative methods. Here’s how:
Modal dialogs and pop-ups
- Focus management: When a modal dialog or pop-up opens, move the keyboard focus to the first focusable element within the dialog.
- Trap focus: Prevent keyboard focus from escaping the modal until it is closed. This can be done using JavaScript and ARIA attributes (e.g.,
aria-modal="true"). - Provide a clear close mechanism: Ensure the modal can be closed using the keyboard (e.g., Escape key, Enter key on a close button).
- Return focus: When the modal is closed, return the keyboard focus to the element that originally triggered the modal.
Interactive widgets
- Test for traps: Thoroughly test interactive widgets and custom components using only the keyboard to identify any potential traps.
- Provide escape routes: Ensure keyboard focus can be moved out of the widget using the Tab key or other standard keyboard navigation.
- ARIA attributes: Use ARIA attributes like
aria-activedescendantto manage focus within complex widgets and ensure proper keyboard navigation.
tabindex attribute
- Use with caution: Use
tabindexsparingly and only when necessary. Avoid usingtabindexvalues greater than 0, as this can create an illogical tab order. - Remove from non-interactive elements: Do not use tabindex on elements that are not interactive (e.g.,
<div>,<span>).
Provide clear instructions
- Alternative exit methods: If a component requires a non-standard exit method (e.g., a specific key combination), provide clear instructions to users before they enter that component.
Testing
- Keyboard-only testing: Test all interactive functionality using only the keyboard to identify any keyboard traps.
- Assistive technology testing: Test with screen readers to ensure that keyboard navigation is smooth and predictable.
Example
If you have a modal dialog, ensure that the focus moves to the first focusable element (e.g., a close button) inside the modal when it opens. The Escape key closes the modal. The focus returns to the element that triggered the modal when it closes.
By implementing these techniques, you can prevent keyboard traps and ensure that all users can navigate your website freely and efficiently using only the keyboard.
