Keyboard Trap

A keyboard trap occurs when a keyboard user navigates into a component or
region of a page and cannot navigate out of it using standard keyboard controls.
The user is stuck — Tab and Shift+Tab do not move focus away, and no other
key provides an escape route. This is one of the most severe accessibility
failures as it can render the rest of a page completely unreachable.
^[1]

When keyboard traps are intentional vs accidental

Intentional focus trapping inside an open modal dialog is correct and
required behaviour. Focus should not leave the dialog while it is open.
However the user must always be able to close the dialog — typically with
Escape — which releases the trap.
^[2]

Accidental keyboard traps occur when a component intercepts Tab key
events without providing a way to exit. Common causes include:

• Embedded iframes that capture all keyboard input
• Custom rich text editors that use Tab for indentation without providing
  an alternative exit key
• Third-party widgets (chat windows, cookie banners, video players) that
  trap focus without an Escape handler
• JavaScript that prevents default behaviour on keydown events globally

How to detect it

Automated scanners cannot reliably detect keyboard traps — they require
operating the page by keyboard to discover.
^[3]

Manual testing steps:

1. Tab into the suspected component
2. Press Tab repeatedly — does focus move out of the component eventually?
3. Press Shift+Tab — can you navigate backwards out?
4. Press Escape — does this release focus if inside a dialog or overlay?
5. If Tab is used for indentation (e.g. rich text editors), is there an
   alternative key documented (typically Escape or Ctrl+Shift+M)?

How to fix it

For modal dialogs:
Implement a proper focus trap that cycles focus within the dialog and
releases it when Escape is pressed or the dialog is closed.

For iframes:
Ensure the iframe title is set and that keyboard users can Tab out of
it naturally. Test with keyboard across browsers — iframe focus behaviour
varies.

For rich text editors:
If Tab is used for indentation, document this and provide Escape or
another key to exit the editor. Announce this to users via an accessible
instruction before or within the editor.

For third-party widgets:
Raise the issue with the vendor. As a temporary measure, consider
positioning such widgets so they appear at the end of the DOM tab order,
reducing the impact of any trapping behaviour.
^[1]

References

1. W3C Web Accessibility Initiative. Understanding Success Criterion 2.1.2: No Keyboard Trap. https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html ↑
2. W3C Web Accessibility Initiative. ARIA Authoring Practices Guide — Dialog Pattern. https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/ ↑
3. Accessible.org. Automated Scans and WCAG Criteria. https://accessible.org/automated-scans-wcag/ ↑