-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split aria-state-or-property-permitted-5c01ea.md #2036
base: develop
Are you sure you want to change the base?
Changes from 11 commits
40c7bcd
8fa2b87
5684a7b
eb972cc
70c2b03
a25586b
801d482
7269b20
2fd88a3
6619581
3e422c7
cf19faa
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
@@ -0,0 +1,160 @@ | ||||||||||
--- | ||||||||||
id: yyw7k3 | ||||||||||
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 | ||||||||||
previous_authors: | ||||||||||
- 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][namespaced element] that is [included in the accessibility tree][]. | ||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't know if you meant for this rule to skip prohibited attributes on role=none/presentation/generic, but by using Included in the accessibility tree that's what happens. Those aren't in the accessibility tree. That stuff is covered by Decorative element not exposed though, so maybe that's okay? I don't think ARIA WG intended for those to be ignored. In ARIA 1.2 that includes almost all prohibited attributes. One thing you could do here is to use programmatically hidden instead:
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Failed example 1 shows a failure on a generic role, so we would either need to change the applicability here, or we need to remove that example. |
||||||||||
|
||||||||||
## Expectation | ||||||||||
|
||||||||||
No test target is [prohibited](https://www.w3.org/TR/wai-aria-1.2/#prohibitedattributes) on the semantic role of the element on which it is specified. | ||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder if semantic role is right here. It creates this strange interaction with presentational conflict resolution. If you agree with my suggestion on the applicability, the perhaps what needs to go here is something like this:
Suggested change
|
||||||||||
|
||||||||||
## 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][sc131] or [4.1.2 Name, Rule Value][sc412]. | ||||||||||
|
||||||||||
Assessing the value of the attribute is out of scope for this rule. | ||||||||||
|
||||||||||
### Related rules | ||||||||||
|
||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This rule has an interesting interaction with Decorative element not exposed. It almost seems to me that this rule should cover everything that rule does, except that you've sidestepped all the overlapping cases by looking at elements included in the accessibility tree, which avoid anything role=none/presentation.
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. With your suggested change to the applicability, we would have some overlapping cases, which I think might just complicate things. As I've been digging more into it, I'm becoming more inclined to leave the applicability and expectation as they are. With that said, I think its still work adding this as a related rule so I'm going to add this suggestion in. |
||||||||||
- [ARIA state or property has valid value](https://www.w3.org/WAI/standards-guidelines/act/rules/6a7281/proposed/) | ||||||||||
- [ARIA state or property is permitted](https://www.w3.org/WAI/standards-guidelines/act/rules/5c01ea/proposed/) | ||||||||||
|
||||||||||
### Bibliography | ||||||||||
|
||||||||||
- [Understanding Success Criterion 4.1.1: Parsing](https://www.w3.org/WAI/WCAG21/Understanding/parsing.html) | ||||||||||
- [Understanding Success Criterion 4.1.2: Name, Role, Value](https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html) | ||||||||||
- [WAI-ARIA 1.2, Supported States and Properties](https://www.w3.org/TR/wai-aria-1.2/#states_and_properties) | ||||||||||
- [WAI-ARIA 1.2, Global States and Properties](https://www.w3.org/TR/wai-aria-1.2/#global_states) | ||||||||||
- [ARIA5: Using WAI-ARIA state and property attributes to expose the state of a user interface component](https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA5) | ||||||||||
- [Document conformance requirements for use of ARIA attributes in HTML](https://www.w3.org/TR/html-aria/#docconformance) | ||||||||||
|
||||||||||
## Test Cases | ||||||||||
|
||||||||||
### Passed | ||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||||||||||
|
||||||||||
#### Passed Example 1 | ||||||||||
|
||||||||||
The `aria-pressed` [state][] is [supported][] for the `button` role, which is the [implicit role][] for `button` elements. | ||||||||||
|
||||||||||
```html | ||||||||||
<button aria-pressed="false">My button</button> | ||||||||||
``` | ||||||||||
|
||||||||||
#### Passed Example 2 | ||||||||||
|
||||||||||
The `aria-pressed` [state][] is [supported][] for the `button` role, which is the [explicit role][] of this `div` element. | ||||||||||
|
||||||||||
```html | ||||||||||
<div role="button" aria-pressed="false">My button</div> | ||||||||||
``` | ||||||||||
|
||||||||||
#### Passed Example 3 | ||||||||||
|
||||||||||
The `aria-labelledby` [property][] is [supported][] for the `textbox` role, which is the [implicit role][] for and `input` element with `type="text"`. | ||||||||||
|
||||||||||
```html | ||||||||||
<input name="searchtxt" type="text" aria-labelledby="searchbtn" /> | ||||||||||
<input name="searchbtn" id="searchbtn" type="submit" value="Search" /> | ||||||||||
``` | ||||||||||
|
||||||||||
### Failed | ||||||||||
|
||||||||||
#### Failed Example 1 | ||||||||||
|
||||||||||
The `aria-label` property is [prohibited](https://www.w3.org/TR/wai-aria-1.2/#prohibitedattributes) for an element with a generic role. | ||||||||||
|
||||||||||
```html | ||||||||||
<div aria-label="Bananas"></div> | ||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure this element is actually in the accessibility tree. ARIA 1.3 draft contradicts itself on that:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I could leave or delete this example, I think we could point to this sentence and say that it should be in the tree.
|
||||||||||
``` | ||||||||||
|
||||||||||
#### Failed Example 2 | ||||||||||
|
||||||||||
The `aria-labelledby` property is [prohibited](https://www.w3.org/TR/wai-aria-1.2/#prohibitedattributes) for an element with an emphasis role. | ||||||||||
|
||||||||||
```html | ||||||||||
<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](https://www.w3.org/TR/wai-aria-1.2/#prohibitedattributes) for an element with a generic role. | ||||||||||
|
||||||||||
```html | ||||||||||
<div aria-roledescription="fruit"><p>Banana</p></div> | ||||||||||
``` | ||||||||||
|
||||||||||
### Inapplicable | ||||||||||
|
||||||||||
#### Inapplicable Example 1 | ||||||||||
|
||||||||||
This `div` element has no [WAI-ARIA state or property][]. | ||||||||||
|
||||||||||
```html | ||||||||||
<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. | ||||||||||
|
||||||||||
```html | ||||||||||
<div role="button" aria-sort="" style="display:none;"></div> | ||||||||||
``` | ||||||||||
|
||||||||||
[explicit role]: #explicit-role 'Definition of Explicit Role' | ||||||||||
[implicit role]: #implicit-role 'Definition of Implicit Role' | ||||||||||
[included in the accessibility tree]: #included-in-the-accessibility-tree 'Definition of Included in the Accessibility Tree' | ||||||||||
[presentational roles conflict resolution]: https://www.w3.org/TR/wai-aria-1.2/#conflict_resolution_presentation_none 'Presentational Roles Conflict Resolution' | ||||||||||
[property]: https://www.w3.org/TR/wai-aria-1.2/#dfn-property 'Definition of Property' | ||||||||||
[semantic role]: #semantic-role 'Definition of Semantic Role' | ||||||||||
[state]: https://www.w3.org/TR/wai-aria-1.2/#dfn-state 'Definition of ARIA State' | ||||||||||
[supported]: https://www.w3.org/TR/wai-aria-1.2/#supportedState 'Definition of Supported ARIA States and Properties' | ||||||||||
[wai-aria state or property]: https://www.w3.org/TR/wai-aria-1.2/#state_prop_def 'Definition of ARIA States and Properties' | ||||||||||
[namespaced element]: #namespaced-element | ||||||||||
[sc131]: https://www.w3.org/TR/WCAG21/#info-and-relationships | ||||||||||
[sc412]: https://www.w3.org/TR/WCAG21/#name-role-value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How would you feel about having this rule as a replacement of "Element marked as decorative is not exposed"? I think right now this rule avoids most overlap between the two rules, but it seems to me that the way the ARIA WG intends prohibited attributes to work, this rule isn't broad enough, and most of what it's missing is covered by the other rule. I left a couple suggestions, if you want to go that direction, I think we should consider deprecating the other rule.
@Jym77 I would appreciate it you'd weigh in on this too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I apparently missed this comment on my first look through. I agree with the sentiment here though, if we want to expand this rule with the applicability you suggested, then I think we should deprecate "Element marked as decorative is not exposed". Additionally, since "Element marked as decorative" doesn't have any accessibility requirements, including those failed cases under this rule would give more direction on what we think reporting requirements are.
TL;DR - In favor of expanding this rule and deprecating "Element marked as decorative"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seemed to have missed the initial comment also… No fully sure I remember all the details, but…
aria-hidden
no focusable content" and "presentational children no focusable content") can be consolidated into "presentational conflict is not triggered" (Merge "Element with aria-hidden has no focusable content" (6cfa84) and "Element with presentational children has no focusable content" (307n5z) #1507). It seems all 3 check a different aspect of the conflict. I've also gathered from a couple of discussions that ARIA group more or less considers triggering the conflict as an author error (even though it didn't make to the spec).aria-label(led-by)
) without triggering the conflict.role="none" aria-label="foo"
does trigger the conflict, thus the role is notnone
and the element is included in the accessibility tree (plus, thearia-label
may be not prohibited on the effective role). I think we concluded that ARIA intention was to consider this as a prohibited attribute nonetheless.So, I'm rather in favour of deprecating "element marked as decorative" which is a bit half-baked and too narrow in its focus, and that we can do much better in terms of intention now. But I'm not sure that this rule is the best fit for the deprecation. I'm also not against a bit of overlap between "attribute not prohibited" and "conflict not triggered" rules, given that they do test with very different focus in mind, and also report a lot of different things on their own.