# Keyboard Trap: WCAG 2.1.2 Explained and Fixed

Source: https://allyway.ai/glossary/keyboard-trap

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](https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html) is a Level A criterion of [WCAG 2.2](https://allyway.ai/regulations/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](https://allyway.ai/regulations/en-301-549) (clause 9.2.1.2) it also applies under the [European Accessibility Act](https://allyway.ai/regulations/eaa).

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 |

> **Note:** > **Intended focus trap vs. keyboard trap**
> Developers say "focus trap" for the deliberate pattern in modal dialogs. It only becomes a WCAG keyboard trap when there is no keyboard way out.

## Examples

```html title="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:** 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:** 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](https://allyway.ai/glossary/keyboard-navigation) test. Test with a visible focus indicator – without [focus visible](https://allyway.ai/glossary/focus-visible), it is hard to tell whether focus is stuck or just invisible.

## How to find a keyboard trap



## Questions

Q: What is a keyboard trap?
A: 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.

Q: Is a focus trap in a modal dialog a WCAG violation?
A: 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.

Q: Which keys count as standard exit methods?
A: 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.

Q: Do third-party embeds count for WCAG 2.1.2?
A: 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.

Q: How do I find a keyboard trap on my website?
A: 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](https://allyway.ai/free-wcag-accessibility-scanner-for-websites) as well.