Skip to content

New rule: role is permitted #2084

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.

Sign up for GitHub

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

Open
wants to merge 19 commits into
base: develop
Choose a base branch
from
Open

New rule: role is permitted #2084

Changes from 3 commits
Commits
Show all changes
19 commits
Select commit Hold shift + click to select a range
692b313
Create new rule
Jym77 Jul 13, 2023
fdbdbfd
Merge branch 'develop' into aria-role-permitted
Jym77 Aug 17, 2023
05cd71b
Merge branch 'develop' into aria-role-permitted
Jym77 Aug 17, 2023
a9ffc70
Apply suggestions from review
Jym77 Aug 17, 2023
aea2cbd
Typo
Jym77 Aug 17, 2023
53875b0
Merge branch 'develop' into aria-role-permitted
Jym77 Aug 31, 2023
c8a6432
Merge branch 'develop' into aria-role-permitted
Jym77 Sep 28, 2023
81a2a82
Add more test cases
Jym77 Sep 28, 2023
c302b75
Refine Applicability
Jym77 Oct 5, 2023
80350ac
Merge branch 'develop' into aria-role-permitted
Jym77 Nov 30, 2023
3157e39
Merge branch 'develop' into aria-role-permitted
Jym77 Jan 11, 2024
69bf415
Merge branch 'develop' into aria-role-permitted
Jym77 Feb 1, 2024
f578d1d
Restrict to non hidden targets
Jym77 Feb 29, 2024
162e213
Merge branch 'develop' into aria-role-permitted
Jym77 Feb 29, 2024
891c9d9
Improve wording of note
Jym77 Mar 1, 2024
bb7a835
Typo
Jym77 Mar 1, 2024
655589f
Merge branch 'develop' into aria-role-permitted
Jym77 Mar 1, 2024
234141a
Merge branch 'develop' into aria-role-permitted
Jym77 Apr 18, 2024
8be5958
Merge branch 'develop' into aria-role-permitted
Jym77 Feb 7, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
125 changes: 125 additions & 0 deletions _rules/aria-role-permitted-j7zzqr.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,125 @@
---
id: j7zzqr
name: ARIA role is permitted.
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
Copy link
Member

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.

The third cell in each row defines the ARIA role values and aria-* attributes which authors MAY specify on the element

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.

Copy link
Contributor

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

Authors MUST NOT use the ARIA role and aria-* attributes in a manner that conflicts with the semantics described in the 4. Document conformance requirements for use of ARIA attributes in HTML and 4.2 Requirements for use of ARIA attributes in place of equivalent HTML attributes tables. ...

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.

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
wcag-technique:ARIA4: # Using a WAI-ARIA role to expose the role of a user interface component
secondary: true
input_aspects:
- Accessibility Tree
- DOM Tree
acknowledgments:
authors:
- Jean-Yves Moyen
---

## Applicability

This rule applies to any [HTML element][namespaced element] that is [included in the accessibility tree][] and 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 [ARIA in HTML specifications][aria in html document conformance].

## Assumptions

There are no assumptions.

## Accessibility Support

There are no accessibility support issues known.

## Background

The presence of an invalid role often implies that the programmatic role do not correspond to the one that is conveyed visually, or that the interactions provided by the elements do not match the ones expected for this role. Therefore, both [Success Criterion 1.3.1 Info and Relationships][sc131] and [Success Criterion 4.1.2 Name, Role, Value][sc412] are secondary requirements for this rule.

[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.

### 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)
- [Understanding SC 1.3.1: Info and Relationships](https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html)
- [Understanding Success Criterion 4.1.2: Name, Role, Value](https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html)
- [Technique ARIA4: Using a WAI-ARIA role to expose the role of a user interface component](https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA4)

## 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>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

```

### Failed

#### Failed Example 1

This `button` element has an [explicit role][] of `heading`, which is not allowed.

```html
<button role="heading">ACT rules</button>
```

### 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>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the background:

This rules apply to every element, even if they are not [included in the accessibility tree][].

Wouldn't that make this a failed example instead of an inapplicable example?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @tbostic32

The applicability are elements with an explicit role defined which is the case.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

@Jym77 Jym77 Sep 28, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 (<li role="presentation">) becomes Inapplicable when it's a clear failure since the only allowed role is listitem.

This is a bit similar to the fact that, in HTML¹, duplicate id are not allowed even though they might very well never cause a single problem. It is nonetheless invalid HTML. Here also, as far as I understand, using the wrong role on a hidden element is invalid ARIA, even if the user never encounter that.

¹: this is not about SC 4.1.1, but HTML/DOM specs

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@giacomo-petri The reason why role="presentation" was taken into account by this rule is that certain elements (e.g., article or aside) explicitly allow it in the list of allowed roles; while some other (like button) also have an explicit list of allowed roles but without presentation being listed.

On looking a bit more closely, it might be that the ones where presentation isn't listed are the elements which are normally focusable, so the conflict would trigger 🤔 I'll look a bit deeper.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 is 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
[sc131]: https://www.w3.org/TR/WCAG21/#info-and-relationships
[sc412]: https://www.w3.org/TR/WCAG21/#name-role-value