ACT Rule a1b64e · proposed
Focusable element has no keyboard trap via standard navigation
This checks whether tabbing through the page ever gets stuck, using only the keys everybody uses, tab and shift-tab.
W3C's implementation table lists no tool or methodology with a consistent implementation of this rule today, which is a statement about what is currently reported rather than about what a machine could do. The rule is proposed, so it has not yet been implemented in full by a tool and reviewed by a W3C working group, and the wording can still change.
Why passing this rule settles nothing about WCAG
W3C's requirements mapping for this rule names no WCAG success criterion as a conformance requirement. That is the position of 24 of the 87 live rules and this is one of them, which is why a scanner can flag it while an auditor leaves it out of the findings. Both of them are reading the same page correctly.
In practice the check is a person with their hands on a keyboard, tabbing through a page and watching where the focus stops, which is a fair part of why nothing has automated it.
Where W3C files this rule
W3C's index lists this rule under the criteria below, which is how most readers arrive here. The rule's own page names none of them as a conformance requirement, so treat the grouping as a signpost rather than as a verdict.
- 2.1.2 No Keyboard Trap Level A
The composite rule this one feeds
This is an atomic input rule, which is why it names no criterion of its own. W3C combines its outcome with the other inputs below, and it is the composite that maps to WCAG. A report that cites this rule id alone has told you about one ingredient, not about the dish.
- Focusable element has no keyboard trap A tool can check this
The normative rule text lives at W3C
What the rule applies to, and exactly what it expects, is published by W3C and can change. We link to it rather than restate it, so nothing here can quietly fall out of date against the source. Read rule a1b64e at W3C.
Focus must be visible, reachable and escapable
Keyboard users move through a page one stop at a time. Three things have to hold at every stop. You can see where you are, you got there in an order that matches the page, and you can leave again.
Break the last one and you create a keyboard trap. The person cannot go forward, cannot go back. Their only way out is to close the tab and lose whatever they had entered.
Custom widgets and modals cause most of these. A dialog that takes focus but never returns it leaves keyboard users stuck inside it with no way out except closing the entire tab.
Fixes that satisfy it
If this rule fails on your site, these are the techniques that put it right.
Other rules W3C files under the same criteria
Each of these asks a different question about the same part of the standard. Passing all of them is still not the same as satisfying the criterion.
- Focusable element has no keyboard trap via non-standard navigation A tool can check this
All 87 ACT rules are grouped by the criteria they test, and 24 of them decide nothing about WCAG on their own. Run a free scan to see which of these your own pages trip.