[NEW RULE] - ARIA required accessible names - aria-required-accessible-name-gp8n89 #2190
Conversation
giacomo-petri
added
the
Rule
giacomo-petri
requested review from
carlosapaduarte,
dd8,
tombrunet,
Jym77,
kengdoj,
colabottles and
HelenBurge
giacomo-petri
changed the title
| description: | | ||
| This rule checks that WAI-ARIA accessible name is available when required. | ||
| accessibility_requirements: | ||
| aria12:accessible_name_required: |
There was a problem hiding this comment.
IIrc, the second part is supposed to be the id of an element in the document so we can link to it (https://github.com/act-rules/act-tools/blob/cc2208ac0df7d53748d977cc7813887cbbf6a0fc/src/act/get-accessibility-requirement.ts and https://github.com/act-rules/act-tools/blob/cc2208ac0df7d53748d977cc7813887cbbf6a0fc/src/rule-transform/rule-content/get-requirements-map.ts), which this is not.
OTOH it doesn't look like there actually is a single place where this is defined 🤔
There was a problem hiding this comment.
@Jym77, exactly. Each role has its own unique requirements, which is why I've given it a general label... I'm uncertain about the best approach to address this.
There was a problem hiding this comment.
🤔 It seems the WAI website currently doesn't show anything for non-WCAG requirements 🙈 (example), where the old site did (example)…
Not sure why it went away, nor what we want to do. @carlosapaduarte do you have an input on that?
Co-authored-by: Jean-Yves Moyen <[email protected]>
| wcag20:1.1.1: # Non-text Content (A) | ||
| secondary: This success criterion is **related** to this rule. This is because elements assigned the ARIA role of `img` or `image` necessitate an accessible name according to WCAG standards. Some of the examples that either pass or fail overlap with this success criterion. | ||
| wcag20:1.3.1: # Info and Relationships (A) | ||
| secondary: This success criterion is **less strict** than this rule. Unlike WCAG, which might not mandate accessible names for certain elements like table elements, this rule requires them. Consequently, some of the failed examples satisfy this success criterion. |
There was a problem hiding this comment.
This feels like a "related to" requirement as well. The way I read 1.3.1, it only applies if the accessible name should come from a visible label, who's relationship isn't available programmatically.
There was a problem hiding this comment.
Although I don't entirely agree with the interpretation, since there might be cases where something is visually clear due to the surrounding context or visual presentation of elements (e.g., a top promo banner carousel without an accessible name, but the section still requires one), I understand the rationale behind it being "related to."
Updating the secondary requirement.
|
|
||
| Although this ARIA rule mandates authors to ensure an [accessible name][] for each [HTML or SVG element][] [included in the accessibility tree][] and possessing a [WAI-ARIA 1.2][wai-aria 1.2] [semantic role][] requiring an [accessible name][], it does not automatically constitute a WCAG accessibility violation. | ||
|
|
||
| For instance, consider a `search` landmark comprising a `form` element with a search label, search input, and search submit button. According to ARIA specifications, both the `search` role and the `form` role necessitate an [accessible name][]. However, adhering strictly to this rule may lead to repetitive announcements by assistive technologies like screen readers, overwhelming users. Therefore, while this might technically breach ARIA specs, it does not necessarily translate to a violation of WCAG accessibility standards. |
There was a problem hiding this comment.
There are some mistakes in this I think. Search doesn't require a name (searchbox does though). And while the form role requires an accessible name, the form element does not have form as its implicit role unless it has an accessible name, in the same way that the img element does not have the img role unless it has a name.
| The `div` element with role `heading` has an empty [accessible name][] due to the empty `aria-label` [attribute value][]. | ||
|
|
||
| ```html | ||
| <div role="heading" aria-level="1" aria-label="">Terms</div> |
There was a problem hiding this comment.
I don't think this fails the rule. Browsers ignore empty aria-labels as far as I'm aware. The AccName spec say to do so too:
https://w3c.github.io/accname/#comp_label
D. AriaLabel: Otherwise, if the current node has an aria-label attribute whose value is not undefined, not the empty string, nor, when trimmed of whitespace, is not the empty string:
| #### Failed Example 7 | ||
|
|
||
| The `div` element with role `heading` has an empty [accessible name][] given by its `aria-labelledby` attribute. | ||
|
|
||
| ```html | ||
| <span id="fail-heading"></span> | ||
| <div role="heading" aria-level="1" aria-labelledby="fail-heading">ACT Rules</div> | ||
| ``` |
There was a problem hiding this comment.
I don't really like this example either. This rule is about checking that elements have accessible names. ACT rules aren't bug trackers to ensure tools have a flawless accessible name calculation.
There was a problem hiding this comment.
I'm not sure I understand the point.
I agree with the previous point (Failed Example 6), as the AccName specifications indicate that empty aria-labels should be ignored.
However, I consider this a clear failure, since the element with the role of heading lacks an accessible name due to improper handling by the author.
Co-authored-by: Wilco Fiers <[email protected]>
|
|
||
|
|
giacomo-petri
dismissed stale reviews from colabottles and Jym77
rule updated, please check again. Thanks
|
|
||
| #### Inapplicable Example 3 | ||
|
|
||
| This `button` element has an [explicit semantic role][] of `none`. leading to a conflict resolved by [Presentational Roles Conflict Resolution][], which is not covered by this rule. |
There was a problem hiding this comment.
| This `button` element has an [explicit semantic role][] of `none`. leading to a conflict resolved by [Presentational Roles Conflict Resolution][], which is not covered by this rule. | |
| This `button` element has an [explicit semantic role][] of `none`, leading to a conflict resolved by [Presentational Roles Conflict Resolution][], which is not covered by this rule. |
|
|
||
| #### Failed Example 7 | ||
|
|
||
| The `button` element has an empty [accessible name][] given by its `aria-labelledby` attribute. |
There was a problem hiding this comment.
I know it's mentioned in the background, but do we need to have a failed example where all major browsers ignore the accessible name computation rules and do provide the button with an accessible name?
New rule:
The aim of this new rule is to guarantee that ARIA roles requiring an accessible name meet the specified requirements.
Closes issue(s): #2119
Need for Call for Review:
This will require a 2 weeks Call for Review
Pull Request Etiquette
When creating PR:
developbranch (left side).After creating PR:
Rule,DefinitionorChore.When merging a PR:
How to Review And Approve