ACT Rule 4e8ab6
Element with role attribute has required states and properties
Some ARIA roles are incomplete without particular attributes. A checkbox has to say whether it is checked. A slider has to say where it sits. This rule checks that an element with an explicit role carries the attributes its role requires.
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.
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.
The conformance requirement here belongs to WAI-ARIA, not to WCAG. W3C lists 1.3.1 and 4.1.2 as related and explains that browsers often fall back on a non-standard default which may be enough, so some failing examples still satisfy the criteria. What a person has to check is whether the control announces its state correctly in a screen reader, because that is what the criterion is about.
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.
- 1.3.1 Info and Relationships Level A
- 4.1.2 Name, Role, Value Level A
The ARIA requirement this rule answers to
This rule maps to ARIA 1.2, section 5.2.2 Required States and Properties. 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 4e8ab6 at W3C.
ARIA attributes have rules that must be followed
ARIA lets you tell assistive technology what something is. That only works if what you tell it is true and complete. A role often carries obligations. Some need particular states set, some need a specific parent, some need particular children.
A tab has to live in a tablist. A checkbox has to say whether it is checked. Leave those out and you have described something that does not exist. That is worse than describing nothing.
Half-finished ARIA is the pattern. Someone adds role="tablist" to get the semantics and stops there. The tabs never announce their state and the widget becomes unusable by voice.
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
- Form field has non-empty accessible name A tool can check this
- Headers attribute specified on a cell refers to cells in the same table element 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.