act-rules
Rule: ARIA state or property is not prohibited
id: name: ARIA state or property is not prohibited rule_type: atomic description: | This rule checks that WAI-ARIA states or properties are not prohibited for the element they are specified on. accessibility_requirements: wcag-technique:ARIA5: # Using WAI-ARIA state and property attributes to expose the state of a user interface component forConformance: false failed: not satisfied passed: further testing needed inapplicable: further testing needed aria12:state_property_processing: title: ARIA 1.2, 8.6 State and Property Attribute Processing forConformance: true failed: not satisfied passed: satisfied inapplicable: satisfied wcag20:1.3.1: # Info and Relationships (A) secondary: true wcag20:4.1.2: # Name, Role, Value (A) secondary: true input_aspects:
- Accessibility Tree
- CSS styling
- DOM Tree
acknowledgments:
authors:
- Trevor Bostic
- Anne Thyme Nørregaard
- Jean-Yves Moyen funding:
- WAI-Tools assets:
- JFK's "We Choose the Moon" speech excerpt is courtesy of NASA.
Applicability
This rule applies to any WAI-ARIA state or property that is specified on an HTML or SVG element that is included in the accessibility tree.
Expectation
No test target (i.e., state or property) is prohibited on the semantic role of the element on which it is specified.
Assumptions
There are no assumptions.
Accessibility Support
Implementation of Presentational Roles Conflict Resolution varies from one browser or assistive technology to another. Depending on this, some elements can have a semantic role of none and their attributes fail this rule with some technologies but users of other technology would not experience any accessibility issue.
Background
The presence of prohibited ARIA attributes is often the result of a developer using an incorrect role, or a misunderstanding of the attribute. These attributes are ignored by browsers and other assistive technologies. This often means that a state or property which should exist is missing. This can cause issues under success criterion 1.3.1 Info and Relationships or 4.1.2 Name, Rule Value.
Assessing the value of the attribute is out of scope for this rule.
Related rules
Bibliography
- Understanding Success Criterion 4.1.1: Parsing
- Understanding Success Criterion 4.1.2: Name, Role, Value
- WAI-ARIA 1.2, Supported States and Properties
- WAI-ARIA 1.2, Global States and Properties
- ARIA5: Using WAI-ARIA state and property attributes to expose the state of a user interface component
- Document conformance requirements for use of ARIA attributes in HTML
Test Cases
Passed
Passed Example 1
The aria-pressed state is supported with button, which is the implicit role for button elements.
<button aria-pressed="false">My button</button>
Passed Example 2
The aria-pressed state is supported with button, which is the explicit role of this div element.
<div role="button" aria-pressed="false">My button</div>
Failed
Failed Example 1
The aria-label property is prohibited for an element with a generic role.
<div aria-label="Bananas"></div>
Failed Example 2
The aria-labelledby property is prohibited for an element with an emphasis role.
<label id="importance">A very important fruit</label>
<p><em aria-labelledby="importance">Bananas</em> are a great fruit</p>
Failed Example 3
The aria-roledescription property is prohibited for an element with a generic role.
<div aria-roledescription="fruit"><p>Banana</p></div>
Inapplicable
Inapplicable Example 1
This div element has no WAI-ARIA state or property.
<div role="region">A region of content</div>
Inapplicable Example 2
This div element is not included in the accessibility tree, hence its WAI-ARIA state or property is not checked.
<div role="button" aria-sort="" style="display:none;"></div>
From the discussion in our ACT TF meeting, we wanted to separate state and property are permitted from state and property are prohibited. This does create a little weirdness where the passed examples are pulled directly from the ARIA state or property is permitted rule.
@carlosapaduarte I wasn't quite sure, for some reason I had thought most new rules started out as issues and then got changed to PRs when there was more group consensus. I can move it into a PR if that is easier.
@tbostic32 We do that when the new rule is still at an idea stage and needs more fleshing out than this one, which is already near completion 😀