Testing & Scanners

Keyboard Traps: How to Find and Fix Them

Last updated May 24, 2026

WCAG Success Criterion 2.1.2 No Keyboard Trap puts it plainly: “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.” The point is to make sure no component on your page becomes a one-way door for someone navigating without a mouse.

The fastest sanity check is hands-on: click into the page body, press Tab repeatedly, and see whether focus ever gets stuck. If it does, try Esc, Shift+Tab, and arrow keys. If none of those release the trap, you have a confirmed SC 2.1.2 failure. The usual suspects are custom rich-text editors that swallow Tab for indentation, embedded iframes (YouTube, Vimeo, Maps) that capture focus without exposing a way back out, and autoplay carousels that move focus on every rotation. The fix is always one of two things: provide a clearly documented keyboard escape mechanism, or restore the native browser behavior the component intercepted.

The 5-minute keyboard-trap test

You do not need any tooling for this. You need a keyboard and a willingness to stop using your mouse for five minutes. Run it on every page that ships interactive widgets, third-party embeds, or modals.

1. Click once into the very top of the page body (or focus the address bar and press Tab into the page).
2. Press Tab repeatedly to walk through every interactive element on the page. Watch the focus ring carefully.
3. Note any place where Tab stops moving forward, cycles inside a single component forever, or where you can no longer reach the browser chrome (the address bar) by repeated tabbing.
4. When you find a stuck spot, try Esc, Shift+Tab, and the arrow keys. Any of these releasing focus is fine; none of them working is a trap.
5. Repeat with each modal, drawer, date picker, video player, and third-party widget on the page.

For a fuller manual sweep — including focus visibility and tab order — pair this with our keyboard navigation guide.

Most common offenders

Eight years of audits across thousands of sites and the same handful of components keep producing keyboard traps. Check these first.

• Rich-text editors and WYSIWYG fields that capture Tab for indentation without offering an escape key (commonly Esc or Ctrl+M to toggle tab-trapping). Quill, TinyMCE, and CKEditor all ship this correctly when configured; in-house editors usually do not.
• Date and time pickers that do not release focus on Esc, or that re-focus their grid every time Shift+Tab tries to exit backward.
• Embedded iframes from YouTube, Vimeo, Google Maps, and Twitter / X. Once focus enters the iframe, keyboard events belong to the embedded document and the parent page has no way to intercept them. If the embed does not expose a documented escape pattern, the user is stuck.
• Auto-play carousels that move focus on rotation. Even when each slide is reachable, focus jumping every five seconds is a usability disaster and can trap users who rely on slow, deliberate tabbing.
• Modal dialogs without Esc (or without a visible, focusable close button). This is the classic case: the intentional focus trap is fine — keyboard users should stay inside the modal while it is open — but if Esc does nothing and there is no close button in the tab order, it becomes a SC 2.1.2 violation.
• Custom drag-and-drop interactions that capture pointer and keyboard events together. Sortable lists built on raw mousedown handlers are the worst offenders — they often forget keyboard users exist at all.
• Cookie banners and chat widgets from third-party scripts. These commonly inject themselves last, trap focus on initial render to force interaction, and ship no keyboard dismiss. Validate every third-party script before shipping it to production.

Fix patterns (before/after)

The mechanics of fixing a trap are almost always the same: add a documented keyboard exit. Below are two of the most common cases — a custom date picker that swallows Tab, and an iframe wrapper that does not let focus out.

Date picker — before

This picker intercepts Tab to move between day cells but never exposes a way to leave the calendar grid. There is no Esc handler and no visible close button in the tab order — a textbook SC 2.1.2 failure.

function DatePicker({ onSelect }: { onSelect: (d: Date) => void }) {
  function handleKeyDown(e: KeyboardEvent) {
    // Tab moves between day cells — and only between day cells.
    if (e.key === 'Tab') {
      e.preventDefault();
      moveToNextDayCell();
    }
    // No Escape handler. No exit. No way out.
  }

  return <div role="grid" onKeyDown={handleKeyDown}>{/* days */}</div>;
}

Date picker — after

The fix keeps the intentional arrow-key navigation inside the grid but restores native Tab behavior and adds Esc to dismiss. The close button is in the tab order, has an accessible name, and returns focus to the input that opened the picker.

function DatePicker({
  onSelect,
  onDismiss,
  triggerRef,
}: {
  onSelect: (d: Date) => void;
  onDismiss: () => void;
  triggerRef: React.RefObject<HTMLButtonElement>;
}) {
  function handleKeyDown(e: KeyboardEvent) {
    // Escape always closes and restores focus to the trigger.
    if (e.key === 'Escape') {
      e.preventDefault();
      onDismiss();
      triggerRef.current?.focus();
      return;
    }
    // Arrow keys move between day cells (standard grid pattern).
    if (['ArrowUp', 'ArrowDown', 'ArrowLeft', 'ArrowRight'].includes(e.key)) {
      e.preventDefault();
      moveCellByArrow(e.key);
      return;
    }
    // Tab is NOT intercepted — native browser focus advance.
  }

  return (
    <div role="dialog" aria-label="Choose a date" onKeyDown={handleKeyDown}>
      <button type="button" onClick={onDismiss} aria-label="Close date picker">
        Close
      </button>
      <div role="grid">{/* days, focusable via arrow keys */}</div>
    </div>
  );
}

Three changes carry the fix: native Tab is restored, Esc dismisses and restores focus, and a visible close button is in the tab order. Same pattern for time pickers, color pickers, and autocomplete listboxes.

Iframe wrapper — before

Once focus enters an embedded video iframe, keyboard events belong to the embedded document. If the embed does not expose a documented exit (most do not), the user is stuck inside the iframe with no way back to the parent page.

<section class="video-section">
  <h2>Watch the demo</h2>
  <iframe
    src="https://www.youtube.com/embed/abcdefghijk"
    title="Product demo"
    allowfullscreen
  ></iframe>
  <a href="/pricing">See pricing</a>
</section>

Iframe wrapper — after

The pragmatic fix is to put the iframe behind a click-to-play poster and apply inert (or tabindex="-1" on the iframe itself) until the user opts in. A “return to page” affordance after the iframe gives keyboard users an explicit way out.

<section class="video-section">
  <h2>Watch the demo</h2>

  <!-- Iframe is inert until the user explicitly chooses to load it. -->
  <button type="button" id="load-demo">Load product demo video</button>

  <iframe
    id="demo-iframe"
    src="https://www.youtube.com/embed/abcdefghijk"
    title="Product demo"
    allowfullscreen
    tabindex="-1"
    inert
  ></iframe>

  <!-- A visible, focusable escape hatch after the iframe. -->
  <a href="#after-video" id="skip-video">Skip past video</a>
  <div id="after-video"></div>

  <a href="/pricing">See pricing</a>
</section>

<script>
  document.getElementById('load-demo').addEventListener('click', () => {
    const f = document.getElementById('demo-iframe');
    f.removeAttribute('inert');
    f.removeAttribute('tabindex');
    f.focus();
  });
</script>

The inert attribute (in every evergreen browser since 2023) removes the subtree from the tab order and accessibility tree until you opt in. The “skip past video” link gives keyboard users a documented exit if the embed's own keyboard model fails them.

What automation catches vs what you test by hand

Automated scanners — including SweepHound — can flag missing tabindex patterns, positive tabindex values, focusable elements with no accessible name, and a handful of structural patterns associated with traps. What no scanner can determine is whether Tab actually escapes from your component in practice. That requires driving the keyboard. SC 2.1.2 is a manual-review item in every serious audit methodology — see our manual accessibility checklist for the full keyboard pass, and our what scanners miss analysis for the broader picture of automated coverage limits.

Modal dialogs: focus trap OK, keyboard trap not OK

To repeat the most important distinction: a modal dialog should trap focus while it is open. The W3C ARIA Authoring Practices dialog pattern requires that focus cycles within the dialog when the user presses Tab past the last focusable element. That is the designed focus trap, and it is not a SC 2.1.2 violation.

The violation begins when the user has no documented way to leave the dialog — Esc does nothing, there is no visible close button in the tab order, and clicking the backdrop is not a keyboard-accessible equivalent. Two checks make this concrete: pressing Esc closes the dialog, and a focusable close button is reachable from inside the dialog. If both pass, your focus trap is a feature; if either fails, it is a bug. We cover the full accessible-dialog pattern in our accessible modals guide.

How SweepHound helps

SweepHound's dual-engine scan flags suspect patterns associated with keyboard traps — positive tabindex values, focusable elements with no accessible name, custom widgets with no detected escape handler, and iframes without surrounding opt-in patterns. The remediation engine generates concrete before/after code for the deterministic cases (tabindex cleanup, missing close-button labels) and flags the rest as manual-review items with a direct link to the 5-minute test above.

We will never tell you a green scan means SC 2.1.2 is satisfied. It is fundamentally a runtime question — does focus actually escape — and that takes a human at a keyboard. What we will tell you is which components warrant the test, so the manual review is finite. To see what a dual-engine scan flags on your site, start a free scan — the manual keyboard checklist is included on every tier. Paid plans add scheduled re-scans, authenticated scanning, and the statement generator; see pricing for details.

For the broader keyboard story — tab order, skip links, focus indicators, and SPA focus management — read our keyboard navigation guide. For the full WCAG 2.2 picture, our WCAG 2.2 checklist covers every Level A and AA criterion with the same practical framing.