WCAG 12.9 — Navigation must not contain a keyboard trap on any web page.

Keyboard trap

The issue

The keyboard trap is one of the most critical accessibility issues because it completely blocks the user. WCAG success criterion 2.1.2 requires that no page component traps the keyboard focus: the user must always be able to leave an interactive element using Tab, Shift+Tab, Escape, or another documented key. A keyboard trap occurs when focus enters a component (iframe, JavaScript widget, video player, rich text editor, interactive map) and can no longer leave. The user presses Tab indefinitely and the focus loops inside the component, never reaching elements beyond it. They are then forced to close the tab or click with the mouse — which is impossible for people who depend exclusively on the keyboard. Keyboard traps most often occur with: third-party widgets embedded via iframe (chatbots, video players, Google Maps, payment forms), WYSIWYG editors (TinyMCE, CKEditor), date picker components, and modals that do not properly manage focus exit. Iframes from third-party services are particularly problematic because the developer has no control over their internal code. Some embedded video players trap focus within their controls. Some chatbots capture focus as soon as they open and provide no keyboard exit mechanism. WCAG considers the keyboard trap a blocking defect. It is one of the rare accessibility issues that renders a page literally unusable for the affected user, with no possible workaround.

Does your site have this issue?

106 RGAA criteria analyzed in 5 minutes by our AI.

Test your site for free

Impact on users

When a keyboard user falls into a trap, they are completely blocked. They can no longer reach the content following the trapping component, nor the navigation links, nor the footer, nor the submit button of a form. Their only recourse is to close the tab and lose their current work. For a person with a motor disability using a switch or breath control system, this situation is even more frustrating because reloading the page and navigating back to the blocking point takes much longer than with a standard keyboard. Blind people using a screen reader are also trapped: the screen reader announces the same elements in a loop without the user understanding why they cannot move forward on the page. This is a disorienting and anxiety-inducing experience. In terms of conformance, a single keyboard trap on a site can fail an entire accessibility audit on this criterion, as it constitutes an absolute barrier to navigation.

Code example

Before (non-compliant)

<!-- Chatbot widget that traps focus -->
<div id="chatbot" tabindex="0" onfocus="openChat()">
  <input type="text" placeholder="Type your message...">
  <button onclick="sendMessage()">Send</button>
  <!-- No close button, no Escape handling -->
</div>

<!-- Modal without focus management -->
<div class="modal" style="display:block">
  <div class="modal-content">
    <input type="text">
    <button>Submit</button>
    <!-- Focus loops between input and button indefinitely -->
  </div>
</div>

After (compliant)

<!-- Chatbot with keyboard close -->
<div id="chatbot" role="dialog" aria-label="Support chat">
  <button type="button" onclick="closeChat()" aria-label="Close chat">
    &times;
  </button>
  <input type="text" placeholder="Type your message...">
  <button onclick="sendMessage()">Send</button>
</div>
<script>
  // Close with Escape
  document.addEventListener('keydown', (e) => {
    if (e.key === 'Escape') closeChat();
  });
</script>

<!-- Modal with controlled focus trap -->
<div class="modal" role="dialog" aria-modal="true" aria-label="Confirmation">
  <div class="modal-content">
    <button type="button" onclick="closeModal()" aria-label="Close">
      &times;
    </button>
    <input type="text">
    <button>Submit</button>
  </div>
</div>

Frequently Asked Questions

How do I detect a keyboard trap on my site?

Navigate your site using only Tab. If at any point you can no longer move forward (focus loops inside a component) or escape with the Escape key, you have a keyboard trap. Scrutia automatically detects keyboard traps during its audit by simulating a complete Tab traversal of the page.

Do iframes always create keyboard traps?

No, not always. A well-designed iframe allows focus to traverse its content and then return to the main page. The problem occurs when the iframe content captures focus without an exit mechanism. This is frequent with poorly developed third-party widgets. Test each iframe on your site with the keyboard.

Should a modal intentionally trap focus?

Yes, but in a controlled manner. A modal should confine focus inside its content (this is 'focus trapping') to prevent the user from interacting with the page behind it. But it must always provide an exit mechanism: a focusable Close button and the Escape key. Focus must return to the triggering element when closed.

What should I do if a third-party widget creates a keyboard trap?

Contact the widget provider to report the issue. If it cannot be fixed, consider replacing the widget with an accessible alternative or isolating it with a bypass mechanism (a skip link to jump past the widget). As a last resort, document the issue in your accessibility statement.

Does your site have this issue?

Scrutia audits your site against WCAG 2.1 AA criteria in 5 minutes. Keyboard navigation, ARIA components, visible focus, contrasts, and much more.

Run a free audit