Skip to content
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

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

Open
wants to merge 13 commits into
base: develop
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
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
171 changes: 171 additions & 0 deletions _rules/aria-allowed-child-element-with-presentational-parent-1g88p9.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,171 @@
---
id: 1g88p9
name: ARIA allowed child element of another element with presentational role
rule_type: atomic
description: |
This rule checks that allowed child element of another element with presentational role does not cause presentational roles conflicts
Comment on lines +5 to +6
Copy link
Member

Choose a reason for hiding this comment

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

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?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

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.

accessibility_requirements:
aria12:conflict_resolution_presentation_none:
title: ARIA 1.2, Presentational Roles Conflict Resolution
forConformance: true
failed: not satisfied
passed: satisfied
inapplicable: satisfied
wcag20:1.3.1: # Info and Relationships (A)
secondary: This success criterion is **related** to this rule. This is because ancestor elements assigned a presentational role with semantic allowed child elements may prevents assistive technologies to convey relationship details, potentially leading to WCAG violations. Some of the examples that either pass or fail overlap with this success criterion.
input_aspects:
- Accessibility Tree
- CSS styling
- DOM Tree
acknowledgments:
authors:
- Giacomo Petri
---

## Applicability

This rule applies to any [HTML or SVG element][] that is [included in the accessibility tree][], is an [allowed child element](https://www.w3.org/TR/wai-aria-1.3/#mustContain) of another element with an [explicit semantic role][] of `none` or `presentation`.

## Expectation

For each target element one of the following is true:
- The element doesn't have any [explicit semantic role][];
- The element has an [explicit semantic role][] of `none` or `presentation`.

## Assumptions

There are no assumptions.

## Accessibility Support

There are no accessibility support issues known.

## Background

While user agents consistently handle elements undergoing [Presentational Roles Conflict Resolution][], authors bear the responsibility of preventing such conflicts.

### Bibliography

- [WAI-ARIA 1.2 - Presentational Roles Conflict Resolution][Presentational Roles Conflict Resolution]

## Test Cases

### Passed

#### Passed Example 1

The `li` elements inherit the presentational role from their `ul` parent element with an [explicit semantic role][] of `none`.

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

#### Passed Example 2

The `tr` and `td` elements inherit the presentational role from their `table` ancestor element with an [explicit semantic role][] of `presentation`.

```html
<table role="presentation">
<tbody>
<tr>
<td>ACT Rules</td>
<td>WCAG</td>
</tr>
<tr>
<td>ARIA</td>
<td></td>
</tr>
</tbody>
</table>
```

#### Passed Example 3

The `li` elements inherit the presentational role from their `ul` parent element with an [explicit semantic role][] of `none`. The `li` have an [explicit semantic role][] of `none`.

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

### Failed

#### Failed Example 1

The `li` elements inherit the presentational role from their `ul` parent element with an [explicit semantic role][] of `none`, but the author forced its [explicit semantic role][] with `listitem`.

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

#### Failed Example 2

The `td` elements inherit the presentational role from their `table` ancestor element with an [explicit semantic role][] of `presentation`, but the author forced its [explicit semantic role][] with `cell`.

```html
<table role="presentation">
<tbody>
<tr>
<td role="cell">ACT Rules</td>
<td role="cell">WCAG</td>
</tr>
<tr>
<td role="cell">ARIA</td>
<td role="cell"></td>
</tr>
</tbody>
</table>
```

### Inapplicable

#### Inapplicable Example 1

The `li` elements are no included in the accessibility tree.

```html
<ul role="none" style="display:none">
<li role="none">WCAG</li>
<li role="none">ARIA</li>
<li role="none">ACT Rules</li>
</ul>
```

#### Inapplicable Example 2

The `ul` element doesn't have a role of `none` or `presentation`.

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

#### Inapplicable Example 3

The `a` elements with a semantic role of `link` are not [allowed child element](https://w3c.github.io/aria/#mustContain) of the `ul` element.

```html
<ul role="presentation">
<a href="https://www.w3.org/TR/WCAG22/">WCAG</a>
<a href="https://w3c.github.io/aria/">ARIA</a>
</ul>
```

[explicit semantic role]: #explicit-role 'Definition of Explicit 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'
[html or svg element]: #namespaced-element
175 changes: 175 additions & 0 deletions _rules/aria-presentational-role-no-global-states-properties-p8g918.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,175 @@
---
Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

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.

id: p8g918
name: ARIA presentational role does not have global states or properties
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 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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

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.

rule_type: atomic
description: |
This rule checks that elements with ARIA presentational role do not have global states or properties
accessibility_requirements:
aria12:conflict_resolution_presentation_none:
title: ARIA 1.2, Presentational Roles Conflict Resolution
forConformance: true
failed: not satisfied
passed: satisfied
inapplicable: satisfied
wcag20:1.3.1: # Info and Relationships (A)
secondary: This success criterion is **related** to this rule. This is because elements assigned a presentational role, but with a global WAI-ARIA state or propert, are exposed in the accessibility tree with their implicit role, potentially leading to WCAG violations. Some of the examples that either pass or fail overlap with this success criterion.
input_aspects:
- Accessibility Tree
- CSS styling
- DOM Tree
acknowledgments:
authors:
- Giacomo Petri
---

## Applicability

This rule applies to any [HTML or SVG element][] that is [included in the accessibility tree][] and has an [explicit semantic role][] of `none` or `presentation`.

## Expectation

Each target element does not have any [global WAI-ARIA state or property](https://w3c.github.io/aria/#dfn-global).

## Assumptions

There are no assumptions.

## Accessibility Support

There are no accessibility support issues known.

## Background

While user agents consistently handle elements undergoing [Presentational Roles Conflict Resolution][], authors bear the responsibility of preventing such conflicts.

If the presentational role is inherited and the element has global WAI-ARIA states or properties, user agents maintain its presentational role regardless of any global ARIA state or property.

### Bibliography

- [WAI-ARIA 1.2 - Presentational Roles Conflict Resolution][Presentational Roles Conflict Resolution]

## Test Cases

### Passed

#### Passed Example 1

The `table` element with role `presentation` does not have any [global WAI-ARIA state or property](https://w3c.github.io/aria/#dfn-global).

```html
<table role="presentation">
<tbody>
<tr>
<td>January</td>
<td>$100</td>
</tr>
<tr>
<td>February</td>
<td>$80</td>
</tr>
</tbody>
</table>
```

#### Passed Example 2

The `h1` element with role `none` has an `aria-colspan` which is a non-global role-specific WAI-ARIA property.

```html
<h1 role="none" aria-level="2">ACT Rules</h1>
```

### Failed

#### Failed Example 1

The `table` element with role `presentation` has an `aria-label` attribute, which is a [global WAI-ARIA state or property](https://w3c.github.io/aria/#dfn-global).

```html
<table role="presentation" aria-label="trend">
<tbody>
<tr>
<td>January</td>
<td>$100</td>
</tr>
<tr>
<td>February</td>
<td>$80</td>
</tr>
</tbody>
</table>
```

#### Failed Example 2

The `h1` element with role `none` has an `aria-describedby` attribute, which is a [global WAI-ARIA state or property](https://w3c.github.io/aria/#dfn-global).

```html
<h1 role="none" aria-describedby="h1-desc">ACT Rules</h1>
<div id="h1-desc">Read more about our intent</div>
```

### Inapplicable

#### Inapplicable Example 1

This `button` element doesn't have an [explicit semantic role][] of `none` or `presentation`.

```html
<button>Submit</button>
```

#### Inapplicable Example 2

This `div` element has an [explicit semantic role][] of `button`, which differs from `none` or `presentation` roles.

```html
<div role="button">Submit</div>
```

#### Inapplicable Example 3

This `button` element with role `none` is not included in the accessibility tree.

```html
<button role="none" style="display:none">Submit</button>
```

#### Inapplicable Example 4

The `li` elements inherits the presentational role from their `ul` parent element, but doesn't have an explicit semantic presentational role itself.

```html
<ul role="none">
<li aria-description="2.2">WCAG</li>
<li>ARIA</li>
<li>ACT Rules</li>
</ul>
```

#### Inapplicable Example 5

The `td` element inherits the presentational role from its `table` ancestor element, but doesn't have an explicit semantic presentational role itself. Moreover, the `td` element with attribute `aria-colspan` has only a non-global role-specific WAI-ARIA property.

```html
<table role="presentation">
<tbody>
<tr>
<td aria-colspan="2">2024</td>
</tr>
<tr>
<td>January</td>
<td>$100</td>
</tr>
<tr>
<td>February</td>
<td>$80</td>
</tr>
</tbody>
</table>
```

[explicit semantic role]: #explicit-role 'Definition of Explicit 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'
[html or svg element]: #namespaced-element
Loading
Loading