WCAG 2.1.2 — No Keyboard Trap

Keyboard Trap

What is this issue?

A keyboard trap occurs when a user navigating with the keyboard enters a component -- such as a modal dialog, embedded video player, or custom widget -- and cannot move focus out of it using standard keys (Tab, Shift+Tab, Escape, or arrow keys). WCAG Success Criterion 2.1.2 (Level A) mandates that if keyboard focus can be moved to a component, it must also be possible to move focus away from that component using keyboard-only navigation.

Keyboard traps are insidious because they are invisible to mouse users. A developer might build a fully functional modal that works perfectly with a mouse but traps keyboard focus inside it because focus management was never implemented. The user presses Tab repeatedly and focus cycles inside the modal forever, with no way to reach the close button or escape back to the page content.

This problem is especially common with third-party widgets: cookie consent banners, chat widgets, embedded maps, WYSIWYG editors, and video players. These components often manage focus internally but fail to release it when the user wants to leave. Custom JavaScript components built without accessibility in mind are another frequent source of keyboard traps.

Impact on users

For people who cannot use a mouse -- including users with motor disabilities, repetitive strain injuries, or tremors -- a keyboard trap is a complete blocker. Once trapped, the only option is to close the browser tab and lose all progress on the page. This is not a minor inconvenience; it makes the site unusable.

Screen reader users are also affected because screen readers rely on keyboard navigation. If focus is trapped inside a widget, the user cannot reach any content that follows it. Power users who prefer keyboard navigation for speed are similarly blocked.

Keyboard traps also violate the principle of user control. Users must always be able to leave a component and continue navigating. A single keyboard trap on a critical path -- such as a checkout flow or a login modal -- can prevent an entire transaction from completing.

Code example

Before (non-compliant)

<!-- Modal that traps focus -->
<div class="modal" tabindex="-1">
  <h2>Subscribe to our newsletter</h2>
  <input type="email" placeholder="Your email">
  <button>Subscribe</button>
  <!-- No close button, no Escape handler -->
  <!-- Focus cycles inside forever -->
</div>

After (compliant)

<!-- Accessible modal with focus management -->
<div class="modal" role="dialog"
     aria-modal="true" aria-labelledby="modal-title">
  <h2 id="modal-title">Subscribe to our newsletter</h2>
  <input type="email" placeholder="Your email">
  <button>Subscribe</button>
  <button aria-label="Close dialog"
          onclick="closeModal()">X</button>
</div>
<script>
  // Trap focus inside modal while open,
  // release on Escape or close button
  dialog.addEventListener('keydown', (e) => {
    if (e.key === 'Escape') closeModal();
  });
</script>

How Scrutia detects this issue

Scrutia's audit engine uses a real browser (Playwright) to simulate keyboard navigation across your pages. It detects keyboard traps by programmatically pressing Tab through every interactive element and flagging any component where focus cycles without an exit. The report identifies the trapped element, its location on the page, and recommends adding Escape key handling and proper focus management.

Check your site for this issue

Scrutia audits your site against WCAG criteria in minutes.

Free audit

Frequently Asked Questions

What is the difference between a keyboard trap and focus trapping?

Focus trapping is a legitimate technique used in modal dialogs to keep focus inside the dialog while it is open -- this is actually required for accessible modals. A keyboard trap, however, is when the user cannot leave the component at all, even by pressing Escape or clicking a close button. The key difference is that proper focus trapping always provides an exit.

Which elements most commonly cause keyboard traps?

The most common culprits are modal dialogs without Escape key handling, embedded iframes (maps, videos), third-party chat widgets, WYSIWYG rich text editors, and custom dropdown menus that capture keyboard events without releasing them.

How do I test for keyboard traps?

Navigate your entire site using only the Tab key and Shift+Tab. Try entering every interactive component and verify you can always leave it. Press Escape inside modals and overlays. If you get stuck anywhere, that is a keyboard trap. Scrutia automates this testing across all your pages.

Is a keyboard trap a Level A or Level AA violation?

Keyboard traps violate WCAG 2.1.2, which is Level A -- the most fundamental level of accessibility. This means it is considered a critical issue that must be fixed for any level of WCAG conformance.

Does your site have this issue?

Scrutia scans your pages against WCAG success criteria and delivers actionable fixes. Results in 5 minutes.

Run a free audit