"Role attribute has valid value" [674b10]: how to enforce WCAG mappings

[Jym77]

Role attribute has valid value has a mapping to 1.3.1 (4.1.2 would be another candidate) which is not always respected. But in man of the cases, a mispelled role is still an accessibility error.

After TF discussion, we tried to remove the mapping in #1854 but this opened concerned from tool vendors that it will effectively remove the rule from the checks that their users care about since they are usually focused on compliance. See also the CG call discussion about removing mappings.

As per the CG call discussion, this tries to add a non-automatable exception to the Expectation to ensure the mapping is correct. I've tried both with 1.3.1 and 4.1.2. The later sounds much better imho, but the mapping is also weaker…

These propositions should likely be taken to the TF for further discussions at some point.

Closes issue(s):

• N/A

Need for Call for Review: N/A, this is mostly for opening discussion.

---

Pull Request Etiquette

When creating PR:

• [X] Make sure you're requesting to pull a branch (right side) to the develop branch (left side).
• [X] Make sure you do not remove the "How to Review and Approve" section in your pull request description

After creating PR:

• [X] Add yourself (and co-authors) as "Assignees" for PR.
• [X] Add label to indicate if it's a Rule, Definition or Chore.
• [ ] Link the PR to any issue it solves. This will be done automatically by referencing the issue at the top of this comment in the indicated place.
• [X] Optionally request feedback from anyone in particular by assigning them as "Reviewers".

When merging a PR:

• [ ] Close any issue that the PR resolves. This will happen automatically upon merging if the PR was correctly linked to the issue, e.g. by referencing the issue at the top of this comment.

How to Review And Approve

• Go to the “Files changed” tab
• Here you will have the option to leave comments on different lines.
• Once the review is completed, find the “Review changes” button in the top right, select “Approve” (if you are really confident in the rule) or "Request changes" and click “Submit review”.
• Make sure to also review the proposed Call for Review period. In case of disagreement, the longer period wins.

[Jym77]

Side question is whether we want to add examples for these exceptions, knowing that it would effectively prevents automated tools to claim a complete implementation 🤔

[Jym77]

Another possibility that we've discussed would be to change the ACT rules format to have both mandatory and optional mappings. For this rule, it would be something like:

Implementation of "Role attribute has valid value" must fail ARIA conformance and may fail 1.3.1 and/or 4.1.2

So, implementation that fail one or the other SC on some or even all test cases would be considered consistent, but implementations that fail 2.1.1 would not be considered consistent. We could revisit some earlier changes in mapping to get them back as optional mappings. This could be use elsewhere, for example to fix #1875.

This could also be used to streamline the button/image button rules by removing the "button not image button" exception from "button has accessible name" and having instead a mandatory mapping to 4.1.2 and an optional to 1.1.1.

[dd8]

Another possibility that we've discussed would be to change the ACT rules format to have both mandatory and optional mappings. For this rule, it would be something like:

Implementation of "Role attribute has valid value" must fail ARIA conformance and may fail 1.3.1 and/or 4.1.2

That seems like a good solution. It might also solve the mapping problem in https://github.com/act-rules/act-rules.github.io/issues/1810#issuecomment-1180888267

Might also be worth considering conditional mappings. For a lot of ARIA issues 4.1.2: Name, Role, Value seems like the best option, but then has problems because it only applies to [user interface components] (https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html#dfn-user-interface-component)

So you could say something like

Must fail 1.3.1 if the widget is visible Must fail 4.1.2 if the widget is a user interface component

That could also fix https://github.com/act-rules/act-rules.github.io/issues/1875. The conditional mapping for an area without alt would be:

Must fail 1.1.1 for area elements

[Jym77]

The ACT rule format is moving toward having secondary requirements, which would be a better way to handle this kind of cases. Closing this.