WCAG 2.1.2Level AOperable

Keyboard Trap: WCAG 2.1.2 Explained and Fixed

Also called: Focus trap, No Keyboard Trap, Trapped focus

Definition

A keyboard trap is a part of a page that keyboard focus can enter but not leave using the keyboard alone. WCAG 2.1.2 No Keyboard Trap forbids it at Level A.

A keyboard trap is a spot on a page where keyboard focus gets stuck: users can Tab into an element – an embedded video player, a map, a chat widget, a broken dialog – but no key brings them back out. For someone who cannot use a mouse, the rest of the page is now unreachable, and often the only way out is to close the tab.

What it means

WCAG 2.1.2 No Keyboard Trap is a Level A criterion of WCAG 2.2. It requires: if focus can be moved to a component with the keyboard, it can also be moved away using only the keyboard. If leaving needs more than the unmodified arrow or Tab keys or other standard exit methods, users must be told how. Through EN 301 549 (clause 9.2.1.2) it also applies under the European Accessibility Act.

This criterion has a special status. Because a trap can make the whole page unusable, WCAG lists it among the requirements that all content on a page must meet – even third-party widgets you do not use to meet any other criterion.

Not every focus restriction is a trap. The W3C explicitly allows keeping focus inside a modal dialog, as long as users can close it:

Situation Verdict
Modal dialog – Tab cycles inside, Esc or "Close" ends it Allowed
Rich text editor – Tab indents, on-screen hint names the exit key Allowed (users are told)
Embedded player – Tab and Esc do nothing, no hint Keyboard trap – fails 2.1.2
Custom widget that intercepts all keys Keyboard trap – fails 2.1.2

Examples

Example
<!-- Keyboard trap: Tab is caught and Esc is ignored -->
<div class="widget" tabindex="0" onkeydown="event.preventDefault()">…</div>

<!-- Accessible modal: focus stays inside, Esc and the button close it -->
<dialog id="newsletter" aria-labelledby="nl-title">
  <h2 id="nl-title">Get our newsletter</h2>
  <label for="nl-mail">Email</label>
  <input id="nl-mail" type="email">
  <button type="button" onclick="this.closest('dialog').close()">Close</button>
</dialog>
<script>document.getElementById('newsletter').showModal();</script>

A native <dialog> opened with showModal() closes on Esc by default. After closing, return focus to the button that opened the dialog, so users continue where they left off.

Do

Let Esc close dialogs and menus, return focus to the trigger after closing, give embedded players and maps a clear keyboard exit, and explain any non-standard exit key on screen.

Don't

Call preventDefault() on every keydown, embed third-party widgets without testing them with the keyboard, or open a modal that has no close button.

A trap usually turns up during a general keyboard navigation test. Test with a visible focus indicator – without focus visible, it is hard to tell whether focus is stuck or just invisible.

How to find a keyboard trap

    Questions

    What is a keyboard trap?

    A part of a page that keyboard focus can enter but not leave with the keyboard. WCAG 2.1.2 No Keyboard Trap (Level A) forbids it.

    Is a focus trap in a modal dialog a WCAG violation?

    No. Keeping focus inside an open modal is expected, as long as users can close it with the keyboard – for example with Esc or a Close button.

    Which keys count as standard exit methods?

    WCAG names unmodified Tab and arrow keys. Esc is a common standard exit on physical keyboards. If your widget needs another key, such as Alt+F10, tell users on screen.

    Do third-party embeds count for WCAG 2.1.2?

    Yes. A keyboard trap anywhere on the page blocks the whole page, so WCAG requires all content to meet 2.1.2 – including embedded players, maps and chat widgets.

    How do I find a keyboard trap on my website?

    Tab through each page template and every widget without a mouse. To catch related issues such as controls without roles or names across your site, run the free WCAG scanner as well.

    • Keyboard Navigation: WCAG 2.1.1 Explained

      Keyboard navigation means that every function of a website can be reached and operated with a keyboard alone – usually with Tab, Shift+Tab, Enter, Space and the arrow keys. WCAG 2.1.1 requires it at Level A.

      Read definition: Keyboard Navigation: WCAG 2.1.1 Explained
    • Focus Visible: WCAG 2.4.7 and Visible Focus Styles

      Focus visible means that a website shows a visible indicator – usually an outline – on the link, button or field that currently has keyboard focus. WCAG 2.4.7 requires it at Level AA.

      Read definition: Focus Visible: WCAG 2.4.7 and Visible Focus Styles
    • Skip Link: Jump Straight to the Main Content

      A skip link is a link at the very top of a page that jumps to the main content, so keyboard and screen reader users do not have to pass the whole menu on every page. It is a sufficient technique for WCAG 2.4.1.

      Read definition: Skip Link: Jump Straight to the Main Content

    Make your website more accessible today

    Built in Europe. Set up in 2 minutes – no developer needed. AI fixes most issues for you.

    1. 1Choose your plan
    2. 2Add one line of code
    3. 3AI fixes your website
    4. Done