Open tbostic32 opened 1 year ago
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.
@tbostic32 This should be a PR, not an issue, correct?
@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 😀
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:
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
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.