ACT Rule 6cfa84
Element with aria-hidden has no content in sequential focus navigation
aria-hidden="true" removes an element and everything inside it from assistive technology, while leaving it on screen and in the tab order. This rule finds hidden containers that still hold something you can tab to.
A tool can decide this one on its own, which is why it turns up in scanner output. The rule is approved, which in W3C's process means it was implemented in full by at least one tool or methodology and then signed off by a working group. Approval is a statement about tools, not a statement that this is the settled way to test the criterion.
What passing this rule proves
When this rule fails, 4.1.2 Name, Role, Value 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.
It is the clearest case of a control existing for one set of users and not another. Focus lands on something a screen reader has been told to ignore, so the person hears nothing at all and has no idea where they are. The rule catches that arrangement. Whether anything else on the page is hidden that should not be is still a person's job.
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.
- 4.1.2 Name, Role, Value Level A
The ARIA requirement this rule answers to
This rule maps to Using ARIA, section 2.4 Fourth Rule of ARIA Use. WAI-ARIA is a separate specification with its own author requirements, so a result here is measured against ARIA rather than against WCAG. A law that names WCAG does not name 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 6cfa84 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.
- Image button has non-empty accessible name A tool can check this
- Link has non-empty accessible name A tool can check this
- ARIA attribute is defined in WAI-ARIA A tool can check this
- ARIA state or property has valid value A tool can check this
- Element with role attribute has required states and properties A tool can check this
- Form field has non-empty accessible name 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.