New rule: role is permitted #2084
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,167 @@ | ||
| --- | ||
| id: j7zzqr | ||
| name: ARIA role is permitted for the element. | ||
| rule_type: atomic | ||
| description: | | ||
| This rule checks that WAI-ARIA roles are allowed for the element they are specified on. | ||
| accessibility_requirements: | ||
| html-aria:docconformance: | ||
| title: ARIA in HTML, 4. Document conformance requirements for use of ARIA attributes in HTML | ||
| forConformance: true | ||
| failed: not satisfied | ||
| passed: satisfied | ||
| inapplicable: satisfied | ||
| input_aspects: | ||
| - Accessibility Tree | ||
| - DOM Tree | ||
| acknowledgments: | ||
| authors: | ||
| - Jean-Yves Moyen | ||
| --- | ||
|
|
||
| ## Applicability | ||
|
|
||
| This rule applies to any [HTML element][namespaced element] which has an [explicit semantic role][explicit role]. | ||
|
|
||
| ## Expectation | ||
|
|
||
| For each test target, its [explicit semantic role][explicit role] is allowed on this element, according to the [ARIA in HTML specification][aria in html document conformance]. | ||
|
|
||
| ## Assumptions | ||
|
|
||
| There are no assumptions. | ||
|
|
||
| ## Accessibility Support | ||
|
|
||
| There are no accessibility support issues known. | ||
|
|
||
| ## Background | ||
|
|
||
| [ARIA in HTML][aria in html document conformance] also defines the [implicit semantic role][implicit role] of each element. Setting the [explicit role][] as the same as the [implicit one][implicit role] is not recommended but nonetheless allowed. This rule doesn't use that in any of its test cases. | ||
Jym77 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| This rules apply to every element, even if they are not [included in the accessibility tree][]. This is because the roles of `none` or `presentation` are only allowed on certain elements. If the rule was only looking at content [included in the accessibility tree][], it wouldn't flag incorrect use of these roles. | ||
|
There was a problem hiding this comment. If an element and its children are not included in the accessibility tree, it doesn't really matter what the roles are. Therefore, it shouldn't be an accessibility problem if these roles are incorrectly used. While I agree that it's technically incorrect, I think it should be considered more as a recommendation rather than a violation - similar to the use of an explicit role that is redundant with the implicit role. @scottaohara Care to comment on the ARIA in HTML position on this one? There was a problem hiding this comment. i mean, yes - if the element is hidden form the accessibility tree then sure, no one can access it / there can't be an issue. the counter point being that if it's rendered in the DOM but marked as hidden, is that because at some point it would be expected that a user could then unhide that content to interact with it? Could excluding something just because it's temporarily hidden not cause a bunch of gotchas for developers who might run a scan, it comes up clean, and then they still get bugs because someone had the audacity to try and use their UI? :) but seriously, i can see the rational to just expose this as a recommendation / needs review - in the hidden state, as long as if it becomes shown it then would be marked as a violation. it just seems like a delay in flagging some issues because maybe someone did a hack-job at 'removing' an errant element, and that shouldn't be called out? There was a problem hiding this comment. @scottaohara With the way that UIs are built these days, what is in the DOM changes with almost every state change. There are often scaffolds that are hidden, and then made whole when they're actually used / made visible. We don't report on a lot of issues in hidden content because of this - teams were frustrated by all of the false positives. While I agree that it's unlikely that an incorrectly used role will be corrected on such a state change, I don't think we should call out a tool as incorrect for ignoring that content completely. |
||
|
|
||
| ### Related rules | ||
|
|
||
| - [Role attribute has valid value](https://www.w3.org/WAI/standards-guidelines/act/rules/674b10/proposed/) checks that the value of the `role` attribute exists in ARIA, while this rule checks that it is allowed on the element using it. | ||
|
|
||
| ### Bibliography | ||
|
|
||
| - [Document conformance requirements for use of ARIA attributes in HTML](https://www.w3.org/TR/html-aria/#docconformance) | ||
|
|
||
| ## Test Cases | ||
|
|
||
| ### Passed | ||
|
|
||
| #### Passed Example 1 | ||
|
|
||
| This `a` element has an [explicit role][] of `button`, which is allowed. | ||
|
|
||
| ```html | ||
| <a href="https://www.w3.org/WAI/standards-guidelines/act/rules/" role="button">All ACT rules</a> | ||
| ``` | ||
|
|
||
| #### Passed Example 2 | ||
|
|
||
| This `h1` element has an [explicit role][] of `tab`, which is allowed | ||
|
|
||
| ```html | ||
| <h1 role="tab">ACT rules</h1> | ||
|
There was a problem hiding this comment. I'm not a huge fan of doing this, as there are more requirements for tab to be valid, like that it needs to be in a tablist. I think either a different role is needed here, or this needs to be made a fully valid tab. |
||
| ``` | ||
|
|
||
| #### Passed Example 3 | ||
|
|
||
| These `hr` elements have an [explicit role][] of `presentation`, which is allowed | ||
|
|
||
| ```html | ||
| Fruits: | ||
| <ul> | ||
| <li>Apple | ||
| <hr role="presentation"/> | ||
| </li> | ||
| <li>Banana | ||
| <hr role="presentation"/> | ||
| </li> | ||
| <li>Orange</li> | ||
| </ul> | ||
| ``` | ||
|
|
||
| ### Failed | ||
Jym77 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| #### Failed Example 1 | ||
|
|
||
| This `button` element has an [explicit role][] of `heading`, which is not allowed. | ||
|
|
||
| ```html | ||
| <button role="heading">ACT rules</button> | ||
| ``` | ||
|
|
||
| #### Failed Example 2 | ||
|
|
||
| This `aside` element has an [explicit role][] of `navigation`, which is not allowed. | ||
|
|
||
| ```html | ||
| <aside role="navigation"> | ||
| <a href="https://www.w3.org">W3C</a> <a href="https://www.w3.org/TR/WCAG21/">WCAG 2.1</a> <a href="https://www.w3.org/WAI/standards-guidelines/act/rules/"> ACT rules</a> | ||
| </aside> | ||
| ``` | ||
|
|
||
| #### Failed Example 3 | ||
|
|
||
| These `h1` elements have an [explicit role][] of `listitem`, which is not allowed; the `div` element has an [explicit role][] of `list`, which is allowed. | ||
|
|
||
| ```html | ||
| Fruits: | ||
| <div role="list"> | ||
| <h1 role="listitem">Apple</h1> | ||
| <h1 role="listitem">Banana</h1> | ||
| <h1 role="listitem">Orange</h1> | ||
| </div> | ||
| ``` | ||
|
|
||
| #### Failed Example 4 | ||
|
|
||
| The first `li` element has an [explicit role][] of `presentation`, which is not allowed. | ||
|
|
||
| ```html | ||
| Fruits: | ||
| <ul> | ||
| <li role="presentation">Apple</li> | ||
| <li>Banana</li> | ||
| <li>Orange</li> | ||
| </ul> | ||
| ``` | ||
|
|
||
| ### Inapplicable | ||
|
|
||
| #### Inapplicable Example 1 | ||
|
|
||
| There is no [HTML element][namespaced element]. | ||
|
|
||
| ```svg | ||
| <svg xmlns="http://www.w3.org/2000/svg"> | ||
| <title>This is an SVG</title> | ||
| </svg> | ||
| ``` | ||
|
|
||
| #### Inapplicable Example 2 | ||
|
|
||
| This `button` element is not [included in the accessibility tree][]. | ||
|
|
||
| ```html | ||
| <button role="list" style="display:none;">Click me</button> | ||
|
There was a problem hiding this comment. From the background:
Wouldn't that make this a failed example instead of an inapplicable example? There was a problem hiding this comment. I agree with @tbostic32 The applicability are elements with an explicit role defined which is the case. There was a problem hiding this comment. See my other comment. I do think this should be inapplicable to this rule, and the note and applicability rather than this testcase should be modified. However, one or the other needs to change. There was a problem hiding this comment. True, moved it to an Failed case. I think that this is still failing ARIA in HTML, even if it doesn't cause an accessibility problem in the end, so I'd rather keep it that way. ARIA in HTML doesn't specify that the roles are only allowed on elements that are exposed. Moreover, if we restrict the rule to exposed elements, suddenly Failed Example 4 ( This is a bit similar to the fact that, in HTML¹, duplicate ¹: this is not about SC 4.1.1, but HTML/DOM specs There was a problem hiding this comment. In accordance with my comment #2084 (comment), to me, Failed Example 4 is not failing because of the presence of the "presentation" role in a DOM children. Rather, its failure is attributed to the absence of an accessibility child with the role "listitem" within the DOM child. Hence, it is not the "role=presentation" itself that impacts the test result; rather, the test fails due to the absence of a child with the "listitem" role. I agree with Tom that we should consider elements included into the accessibility tree. There was a problem hiding this comment. @giacomo-petri The reason why On looking a bit more closely, it might be that the ones where There was a problem hiding this comment. just going to state one more time that i'd err on the side of flagging this - as otherwise it falls on making a developer/tester have to do more work to find errors, by ensuring they fully comb through a UI and reveal all hidden content. I do acknoweldge there are probably instances of devs hiding problematic markup, rather than fixing it... but should a dev really be surprised to get an error flagged for something they knew was an error and 'hid' it as their 'fix'? |
||
| ``` | ||
|
|
||
| #### Inapplicable Example 3 | ||
|
|
||
| This `a` element does not have an [explicit semantic role][]:. | ||
|
|
||
| ```html | ||
| <a href="https://www.w3.org/WAI/standards-guidelines/act/rules/">All ACT rules</a> | ||
| ``` | ||
|
|
||
| [aria in html document conformance]: https://www.w3.org/TR/html-aria/#docconformance 'ARIA in HTML, Document conformance requirements for use of ARIA attributes in HTML' | ||
| [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' | ||
| [namespaced element]: #namespaced-element 'Definition of Namespaced Element' | ||
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, this is going to be very nit picky.
I don't think the way you're interpreting this requirement is right. Or quite possibly, I think the requirement is written incorrectly. MAY in RFC2119 speak does not create a prohibitive statement. You can use these roles on those elements, and browsers have to support it when you do. But that's not the same as saying authors are not allowed to use other roles. It would have to be something like "if an author specifies a role it MUST be one from the third column."
I think this is a solid rule, and we should definitely have it, but I'm a little reluctant to say this is a conformance requirement for ARIA in HTML. Even if that was the intended meaning, that's not what it says. I don't really want to hold this rule up over a technicality like this, but I do think something needs to be done about this.
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.
@WilcoFiers the sentence you quote needs to be put into the context of section 1 Author requirements fo ruse of ARIA in HTML
per section 1, it's an Authors MUST NOT - where the Author MAYs specificy what it allowed.
if you think this is unclear because one has to piece together these different parts of the specification, then that's fair. The spec can be updated to restate the author requirements more overtly in tandem with the text you quoted.