You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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:
acknowledgments:
authors:
funding:
assets:
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
Test Cases
Passed
Passed Example 1
The
aria-pressed
state is supported withbutton
, which is the implicit role forbutton
elements.Passed Example 2
The
aria-pressed
state is supported withbutton
, which is the explicit role of thisdiv
element.Failed
Failed Example 1
The
aria-label
property is prohibited for an element with a generic role.Failed Example 2
The
aria-labelledby
property is prohibited for an element with an emphasis role.Failed Example 3
The
aria-roledescription
property is prohibited for an element with a generic role.Inapplicable
Inapplicable Example 1
This
div
element has no WAI-ARIA state or property.Inapplicable Example 2
This
div
element is not included in the accessibility tree, hence its WAI-ARIA state or property is not checked.The text was updated successfully, but these errors were encountered: