ACT Rule 80af7b · composite · proposed
Focusable element has no keyboard trap
A keyboard trap is a place focus goes into and cannot come out of, and for somebody navigating by keyboard it ends the visit. This composite rule combines the standard navigation check with the non-standard one and passes when either shows a way out.
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.
What passing this rule proves
When this rule fails, 2.1.2 No Keyboard Trap is not satisfied, and that half is certain. When it passes, W3C's own outcome mapping says the criterion still needs further testing. So a green result here is evidence that one specific thing is not broken, and it is the answer W3C gives on 59 of its 87 live rules.
The rule page explains the gap honestly. This rule only asks for an escape in one direction. If the criterion needs a way out both forwards and backwards, a page can pass here and fail there. Tab all the way through, then shift-tab all the way back.
The criteria this rule is a test for
These are the criteria the rule names as its own conformance requirement. Each one is a far bigger question than this rule asks, and our page for it sets out what the whole criterion covers.
- 2.1.2 No Keyboard Trap Level A
The rules this one combines
A composite rule runs no test of its own. It takes the outcomes of the atomic rules below and turns them into one answer, which is how W3C handles a criterion that can be met in more than one way. Not one of them maps to this criterion on its own.
- Focusable element has no keyboard trap via standard navigation Nothing implements this yet
- Focusable element has no keyboard trap via non-standard navigation 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 80af7b 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.
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.