WCAG 2.1.2 — No Keyboard Trap
Some parts of your website trap keyboard users so they cannot navigate away using Tab or arrow keys. People who cannot use a mouse become stuck and cannot access the rest of your site. Under the ADA Title II rule, this prevents equal access and must be fixed.
Who Is Affected
Keyboard-only users, including people with mobility disabilities who cannot use a mouse, users with motor impairments, screen reader users, and anyone navigating with keyboard shortcuts.
What This Means
When someone navigates your website using only the Tab key (or arrow keys), they must be able to move focus away from any component and continue to other parts of the page. A keyboard trap occurs when focus gets stuck in a modal dialog, dropdown menu, carousel, or other interactive element with no way to escape except by using a mouse.
Common keyboard traps include modal dialogs without a close button that responds to Escape key, dropdown menus that don't close when Tab moves to the next element, and embedded content like videos or widgets that capture all keyboard input.
Fix: CMS / Theme
Keyboard traps are typically caused by JavaScript components in your theme or installed plugins/extensions that don't properly handle keyboard navigation.
For Modal Dialogs and Popups
- Ensure all modals can be closed with the Escape key.
- When a modal opens, focus should move to the first focusable element inside it.
- Tab navigation should cycle only within the modal (focus trapping is allowed within modals, but Escape must always work).
- When the modal closes, focus should return to the element that opened it.
For Dropdown Menus
- Pressing Tab should move focus out of an open dropdown to the next focusable element.
- Pressing Escape should close the dropdown and return focus to the trigger button.
- In Joomla, check your template's main navigation settings under Menus → Menu Manager.
- In WordPress, review your theme's navigation options under Appearance → Menus.
For Carousels and Sliders
- Ensure Tab can move focus past the carousel to subsequent page elements.
- Provide keyboard controls (arrow keys) that don't prevent Tab from working normally.
- If using a carousel plugin, check for keyboard accessibility options in the settings.
Fix: Content Editor
If you've embedded content that creates keyboard traps:
- For embedded videos: Ensure the video player allows Tab to move to the next page element after the video controls.
- For iframes: Consider if the embedded content is essential. If so, ensure it doesn't trap keyboard focus.
- For custom widgets: Test that Tab navigation can move past the widget to continue down the page.
Testing Your Fix
- Use only your keyboard to navigate the page.
- Tab through all interactive elements.
- When you encounter dropdowns, modals, or other components, verify you can escape using Tab or Escape.
- Confirm focus moves logically to the next element rather than getting stuck.
Standard Reference
WCAG 2.1 Success Criterion 2.1.2 — No Keyboard Trap, Level A
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.
Check if your government website has this issue
OctoComply scans your website and documents for WCAG 2.1 AA violations. The free tier covers up to 10 pages.
Run a Free Scan