No Keyboard Trap
If keyboard focus can move to a component, focus must also be able to move away from it using only the keyboard. Modals, embeds, and custom widgets are the usual offenders.
What it asks
If a user can Tab into a component, they must be able to Tab (or Shift+Tab, or use another documented key) out of it without picking up the mouse. If something more than the standard arrow/Tab keys is required to exit — for example, Ctrl+M to escape an embedded video player — the user must be informed how.
This is not the same as a focus trap inside a modal, which is a desirable pattern: a modal cycles focus within itself but releases focus when the user closes it. A keyboard trap is when there is no documented way out.
How to meet it
- Inside a modal dialog, cycle focus between the first and last focusable elements with Tab and Shift+Tab, and close the dialog on Escape, returning focus to the trigger.
- For embedded third-party content (video players, maps, iframes from unknown origins), test whether Tab continues past the embed. If it doesn’t, document the exit keystroke near the embed.
- For custom widgets that consume arrow keys (date pickers, comboboxes, tree views), keep Tab as the universal exit — never block it.
- For drag handles or rich-text editors that use Tab for indentation, provide a documented alternative (Escape to release, Ctrl+M to exit edit mode) and surface it in the UI.
Common failures
- Modal dialogs that trap focus but don’t close on Escape and don’t expose a focusable Close button.
- Embedded PDF viewers, Flash relics, and some Tableau / Power BI dashboards that swallow Tab indefinitely.
- Rich-text editors (TinyMCE, CKEditor in older versions) that capture Tab for indenting and never release.
- Custom comboboxes where arrow keys move through options but Tab does nothing — the user gets stuck on the input.
- Cookie banners with focus management that loops without ever offering Accept / Reject focus.
Automated tools rarely catch this — axe and Lighthouse can only flag suspicious patterns. Manual keyboard testing is the only reliable check.
Why it matters
A keyboard trap is one of the most serious accessibility failures: the user is literally unable to leave that part of the page. A blind user might have to refresh, losing their session and any form data. For many users this is the moment they abandon the site entirely. Of all the WCAG criteria, this is the one most likely to make a page legally indefensible — courts and enforcement bodies treat trapping users as a clear barrier.