Understanding WCAG 2.1.2
What is it?
WCAG 2.1.2 No Keyboard Trap is a Level A criterion. If keyboard focus can move onto a component, it has to be able to move back off again using only the keyboard. And if getting out takes more than Tab, the arrow keys, or Escape, the page has to tell you how.
Why it matters
Keyboard users move through a page one stop at a time, using Tab and the arrow keys. If focus gets stuck on a component with no way out, everything past it becomes unreachable. Can’t move forward, can’t go back. Often the only escape is reloading and starting over, or leaving the page entirely.
Who it affects
People…
- Navigating with a keyboard only, no mouse
- Using a screen reader, which relies on keyboard commands
- Using a switch device, sip-and-puff, or on-screen keyboard
- Using voice control mapped to keyboard commands
One important distinction
Holding focus inside an open modal is good practice, not a trap. What makes it a keyboard trap is having no keyboard way out.
Focus kept in a modal plus a clear exit is correct. Focus kept in with no exit is the failure.
Common failures
- A modal you can’t escape. Focus moves into the dialog, but Escape doesn’t close it and the Close button isn’t reachable by keyboard. You’re stuck inside with no way back to the page.
- An embedded widget that swallows focus. A third-party media player, chat widget, or ad grabs focus and won’t give it back. Tab keeps cycling inside it and never returns to your page.
- A custom date picker with no way out. You Tab into the calendar and keep landing on dates. Escape doesn’t close it, and there’s no way to move past it to the next field.
- A focus loop that never ends. Focus cycles through a menu or carousel and never moves on to the rest of the page. Pressing Tab just returns you to the start of the same group with no way out.
- A secret exit key. You can leave, but only by pressing some obscure combination like Ctrl + Alt + M, and nothing on the page tells you. If the exit isn’t a standard key, a keyboard user has no way to guess it.
Solution
Can Tab in? Then you can Tab out.
The rule is simple: for every component, focus has to be able to enter and leave with the keyboard alone. Keep the interaction you want. Just make sure there’s always a way back to the page.
For modal dialogs
Use a native <dialog>. Open it with showModal() and the browser does the hard part for you.
openBtn.addEventListener('click', () => modal.showModal());What you get free:
- Escape closes it
- Focus stays inside while it’s open
- Focus returns to the button that opened it
If you can’t use a native <dialog> and you’re building the modal yourself, you have to do that last part by hand. Capture what had focus before the modal opened, then send focus back there when it closes:
let opener = null;
function openModal() {
opener = document.activeElement; // capture before focus moves
// show the modal, then move focus into it
}
function closeModal() {
// hide the modal
opener?.focus();
opener = null;
}Store it once when the modal opens rather than passing it around. A modal usually closes from several places, the Escape key, the Close button, a click on the backdrop, and none of those know on their own what had focus beforehand.
For embedded and third-party widgets
Test every media player, chat tool, and iframe with the keyboard before you ship it. If one grabs focus and won’t release it, that’s a reason to reconfigure, fix, or replace it.
Worth knowing: an iframe on its own doesn’t trap focus. Browsers Tab into and back out of them normally. When an embed traps you, it’s the widget’s own script intercepting keystrokes inside the frame. That distinction matters when you’re deciding whether to file a bug with the vendor or look at your own code first.
For custom widgets
Start from the ARIA (Accessible Rich Internet Applications) Authoring Practices patterns. They map out the expected keys, including how to close a menu or date picker and return focus to the field it came from. Treat them as a starting point, not the final word, and test thoroughly with real assistive tech before you ship.
If the exit isn’t standard, say so
If leaving a component genuinely needs an unusual key or combination, tell the user right there, like a visible “Press Ctrl + Alt + M to exit.” Better still, make plain Tab work so no one needs instructions at all.
A note on 2.1.1
No Keyboard Trap works alongside 2.1.1 Keyboard (Level A), which says all functionality has to be operable by keyboard. That one gets you in and working. This one makes sure you can always get back out.
How to test
- Set the mouse aside and Tab through the whole page, start to finish.
- At every component, check you can Tab in and Tab back out: menus, modals, embedded players, date pickers.
- If you ever get stuck, ask what key would free you, and whether the page tells anyone that key exists.
Closing
A keyboard trap is one of the fastest bugs to find and one of the most frustrating to hit.
Tab through your site with the mouse put away. If you can always get back out, so can the people who never use a mouse at all.
Learn more
Want more clear and actionable WCAG breakdowns? Check out: wcagInPlainEnglish.com