On each web page, navigation must not contain any keyboard trap. Is this rule followed?
A user navigates by keyboard and enters a rich text editing area. They press Tab to reach the next button. Nothing happens. Shift+Tab: still nothing. Without a mouse, they can no longer move forward or backward on the page. That's a keyboard trap.
A keyboard trap is exactly that: focus enters a component and cannot exit using the keyboard alone. For people who navigate exclusively by keyboard—motor disability, screen reader users, developers testing by tabbing—it's total exclusion from everything that follows the blocking component. The only way out is to close the tab or restart the browser.
The criterion verifies that each element receiving focus allows exiting it: either by Tab or Shift+Tab, or by another keyboard mechanism explicitly communicated to the user. "Susceptible to receiving focus" means elements that actually receive focus, whether reached by tabulation or by script.
Don't confuse a trap with inaccessibility. If a component is never reached by Tab, criterion 12.9 doesn't apply—it's criterion 7.3. Two distinct problems, two distinct fixes.
Un test to detect a possible keyboard trap
Absence of keyboard trap in focusable elements
- Unplug the mouse. Navigate the entire page with Tab, noting each element that receives focus.
- Also identify elements that receive focus via a script (ARIA widgets, interactive components).
- For each focused element, verify that it is possible to exit it:
- With Tab (next element) or Shift+Tab (previous element), OR
- With another keyboard shortcut, provided the user is informed of it on the page (visible text, label, instruction).
- For complex components (radio button groups, ARIA tabs, listbox): only verify that Tab enters the component and that Tab or Shift+Tab exits it to the page. Internal arrow-key navigation is not covered by this test.
Result: if each focusable element allows continuing keyboard navigation, the test is validated. If a single component permanently blocks focus with no keyboard exit, the test fails.
Examples
❌ Non-compliant : Rich text editor that captures Tab without offering an exit
<label for="description">Product description</label>
<div
id="description"
contenteditable="true"
tabindex="0"
onkeydown="handleEditorKeys(event)">
Write your description here
</div>
<button type="submit">Publish</button>The handleEditorKeys function intercepts all keyboard events to manage formatting (indentation, lists, formatting shortcuts). If Tab is captured to insert a tab in the text and neither Shift+Tab nor Escape are handled to exit the component, the user is trapped: the Publish button is completely inaccessible by keyboard. The only way out is to close the tab.
✅ Compliant : Modal dialog box with documented keyboard exit
<button type="button" id="open-modal">Filter results</button>
<div
role="dialog"
aria-modal="true"
aria-labelledby="modal-title"
id="filters-modal"
tabindex="-1">
<h2 id="modal-title">Search filters</h2>
<label for="category">Category</label>
<select id="category">
<option>All</option>
<option value="clothes">Clothing</option>
</select>
<button type="button" id="close-modal">Close (Escape)</button>
</div>
<script>
document.addEventListener('keydown', function(e) {
if (e.key === 'Escape') { closeModal(); }
});
</script>The modal intentionally confines focus inside it while open—this is the expected behavior for role="dialog". But the user can exit at any time via Escape or the Close button. The mention of "Escape" in the button label explicitly informs of the available mechanism, which the criterion requires when exit doesn't happen via Tab. No trap.
Tips and pitfalls
⚠️ Keyboard-inaccessible element ≠ keyboard trap
A component never reached by Tab is not a trap. That's a failure of criterion 7.3 (script controllable by keyboard and pointer). Criterion 12.9 penalizes only elements that receive focus and from which one cannot exit. Checking 12.9 instead of 7.3 in an audit report means directing the wrong fix to the development team.
⚠️ Complex ARIA components: Tab in and out is enough
A radio button group, a listbox, or an ARIA tab system use arrow keys to navigate between their internal options. That's not a trap. Test 12.9.1 only verifies that Tab enters the component and that Tab or Shift+Tab exits it to the rest of the page. Internal arrow-key navigation is outside the scope of this criterion.
💡 Test embedded plugins and iframes first
WYSIWYG editors, third-party video players, interactive maps, and PDF viewers are the components most frequently trapping in real audits. They capture keyboard events for their own shortcuts and forget to handle exit. Enter each iframe or plugin, then immediately test Tab, Shift+Tab, and Escape.
⚠️ The modal is an intentional trap—under conditions
Confining focus to a modal dialog box is the correct behavior per ARIA specifications. It's not a violation of criterion 12.9 if an exit mechanism exists: Escape key, Close button, or any keyboard combination communicated to the user. With no way to close the modal by keyboard, that's a confirmed trap.
⚠️ The near-trap: exit possible but unfindable
Some components technically allow exiting, but the mechanism is so hidden that the user feels trapped—a modal closable by Shift+Tab on the first element, without a button or indication. Technically not a trap under criterion 12.9, but a deeply frustrating experience. Flag it in an audit note with reference to criterion 12.8 if the tab order is incoherent.
Frequently asked questions
How do I audit a keyboard trap concretely according to RGAA?
Unplug the mouse and navigate the entire page with Tab. When focus enters an interactive component, test Tab, Shift+Tab, Escape, and arrow keys. If no key allows continuing navigation, document the component: type, position on the page, keys tested, result. WYSIWYG editors, third-party iframes, and multimedia plugins are priority areas to test.
What exit mechanisms are valid to satisfy RGAA criterion 12.9?
Yes, provided the user is informed of this mechanism. The criterion accepts "another keyboard interaction the user is informed about." If Escape works but is mentioned nowhere on the page, that's not enough. The information can appear in the Close button label, in visible component instructions, or in associated help text.
How do I distinguish a contenteditable legitimately capturing Tab from a keyboard trap?
No, not necessarily. If the component displays visible instruction like "Press Escape to exit the editor" and that key works, criterion 12.9 is met. The problem arises when Tab is captured AND no other keyboard exit is provided or communicated. It's the combination of both that creates the trap.
What's the difference between RGAA criterion 12.9 and criterion 7.3?
Criterion 12.9 applies to elements that receive focus but from which one cannot exit by keyboard. Criterion 7.3 applies to scripts that work only with the mouse, with no keyboard equivalent. A component never reached by Tab falls under 7.3. A reachable but blocking component falls under 12.9. Both can fail on the same page for different reasons and require distinct fixes.