[NEW RULES] - Define author's responsibility when presentational roles conflict arises

[giacomo-petri]

New Rules:

• Check that elements with ARIA presentational role are not focusable
• Check that allowed child element of another element with presentational role does not cause presentational roles conflicts
• Check that elements with ARIA presentational role do not have global states or properties

Closes: #2193

Need for Call for Review:
This will require a 2 weeks Call for Review

---

Pull Request Etiquette

When creating PR:

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

After creating PR:

• Add yourself (and co-authors) as "Assignees" for PR.
• 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.
• 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.

[WilcoFiers]

This rule seems like a subset of our ARIA required context role rule. It requires that elements that can't exist without a parent have that parent. The rule you propose is more focused, but it doesn't seem to cover anything that isn't also covered by the required context rule. Or at least, I can't find anything that isn't.

Would a better solution be to add the one or both of the failed examples to required context instead?

[giacomo-petri]

I see the point.

The intent was to cover a specific ARIA requirement in detail and comprehensively (Presentational Roles Conflict Resolution) to guarantee authors are clear on what to do in these scenarios.

I'm uncertain about the next steps.

The other two existing ARIA requirements are rather more vague but do cover the necessary aspects. If we decide to revert these new rules, we'll still need to add examples to the existing rules.

[WilcoFiers]

I don't think you should have more than one new rule in a PR.

[giacomo-petri]

I apologize for this. I based my work on this pattern: #2167. These three rules are intended to fulfil the "Presentational Roles Conflict Resolution" topic from an author's perspective.

[WilcoFiers]

I'm very sorry to do this a second time. I can tell you've put a lot of work into these, but this rule also seems like a duplicate to me. This time of Element marked as decorative is not exposed . Your version makes slightly different trade-offs about explicitly stating which props cause this problem, whereas the existing rule is vaguer about that. But then in being vaguer and just saying "not in the accessibility tree" its means it can handle changes to the ARIA spec like how aria-label is not a global attr if on role=none, but still fails for creating presentation conflict.

[giacomo-petri]

I see the point.

The intent was to cover a specific ARIA requirement in detail and comprehensively (Presentational Roles Conflict Resolution) to guarantee authors are clear on what to do in these scenarios.

I'm uncertain about the next steps.

The other two existing ARIA requirements are rather more vague but do cover the necessary aspects. If we decide to revert these new rules, we'll still need to add examples to the existing rules.

[WilcoFiers]

See above, the Element marked as decorative is not exposed rule covers this.

I think we can debate splitting the rule up into the two rules you propose. I'd personally lean towards leaving this as is, since the "not exposed" rule is already approved by AG, but if others feel there are good reasons to deprecate it in favor of this I'm open to that conversation.

[giacomo-petri]

I see the point.

The intent was to cover a specific ARIA requirement in detail and comprehensively (Presentational Roles Conflict Resolution) to guarantee authors are clear on what to do in these scenarios.

I'm uncertain about the next steps.

The other two existing ARIA requirements are rather more vague but do cover the necessary aspects. If we decide to revert these new rules, we'll still need to add examples to the existing rules.

[giacomo-petri]

After our conversation with @carlosapaduarte and @dan-tripp-siteimprove during the office hours meeting, I took another look at this item (since it was on me and I forgot about it 🫤).

Although there is certainly overlap with Element marked as decorative is not exposed as mentioned by @WilcoFiers, I still see value in this PR. While it doesn't fully cover the same scope as Element marked as decorative is not exposed - the applicability here is limited to elements that trigger the "presentational role conflict resolution", so examples like are not within the scope of my PR - it does get rid of the ambiguous "marked as decorative" definition.

Additionally, it covers scenarios not currently within the scope of the test, such as:

<a href="https://www.w3.org/WAI/standards-guidelines/act/rules/">
  <button>All ACT Rules</button>
</a>

In this case, the button element is not marked as decorative by the author, so it falls outside the Element marked as decorative is not exposed rule's applicability, but it is still an author error.

and:

<ul role="none">
  <li role="listitem">WCAG</li>
  <li role="listitem">ARIA</li>
  <li role="listitem">ACT Rules</li>
</ul>

In Element marked as decorative is not exposed rule, the <ul> is technically meeting the current requirement because its role is ignored, but it still causes a "presentational role conflict," which leads to an author error.

Furthermore, while I agree there is repetition, the rule's focus is very clear and well-defined, since it specifically addresses all items that fall under the "presentational role conflict" definition.

Is it really a problem if something is duplicated, as long as the scope of the check is clear and unambiguous?