ACT Rule ebe86a · proposed
Focusable element has no keyboard trap via non-standard navigation
When standard tabbing gets stuck there is sometimes another way out, an arrow key or an escape. This rule checks for that escape route in the places where tab alone has already failed.
A tool can decide this one on its own, which is why it turns up in scanner output. 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.
It answers a follow-up question, so it maps to no criterion by itself and the composite it feeds is what decides 2.1.2. A way out that exists but is not signposted is still a trap in practice, and no published rule tests whether anybody could find 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 ebe86a 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 standard navigation Nothing implements this yet
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.