[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]>
|
|
||
|
|
giacomo-petri
dismissed stale reviews from colabottles and Jym77
rule updated, please check again. Thanks
|
|
||
| #### 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?
There was a problem hiding this comment.
acc name computation is changes and now says:
LabelledBy: Otherwise, if the current node has an aria-labelledby attribute that contains at least one valid IDREF, and the current node is not already part of an ongoing aria-labelledby or aria-describedby traversal, process its IDREFs in the order they occur:
so, let's remove this example!
Co-authored-by: Carlos Duarte <[email protected]>
✅ Deploy Preview for act-rules ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
the role="dialog" does no longer require the acc name, as per https://github.com/w3c/aria/pull/2297/files |
|
|
||
| For instance, consider a `search` landmark comprising an element with the `form` role, a search label, a search input, and a search submit button. According to ARIA specifications, the `searchbox` 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. | ||
|
|
||
| Elements subjected to the [Presentational Roles Conflict Resolution][] are not part of this rule and must be tested separately. |
There was a problem hiding this comment.
I'm not sure what to make of this. Does this affect the applicability? If so, does it mean that the applicability should be changed to this:
"... unless the element has a [explicit][explicit semantic role] presentational role which is not to be ignored according to [Presentational Roles Conflict Resolution][]".
?
edit: I just read Inapplicable Example 3, and it seems to contradict my interpretation in my preceding paragraph. Regardless: I get the impression that confliction resolution is a factor in the applicability. If that's true, then that fact should be documented in the applicabililty, not just in the background or examples.
edit number 2: I find is strange that conflict resolution should be a factor in the applicability. Wouldn't it be cleaner to make it not so?
edit number 3: I read some old resolved comments between you and Jean-Yves, and I think I get it now. You really do want to make any element with role="none" and which is subject to conflict resolution inapplicable. That's fine, but I think we can help future confused readers like myself. May I suggest changing this line in the background:
"Elements subjected to the [Presentational Roles Conflict Resolution][] are not part of this rule and must be tested separately."
to this:
"Any element subjected to the [Presentational Roles Conflict Resolution][] is inapplicable under this rule, and must be tested separately. Such an element is inapplicable because it has an [explicit][explicit semantic role] presentational role - even though that presentational role will be ignored by user agents, as a result of conflict resolution."
I don't think we use the term "computed role" around here, but maybe we should consider it at some point.
There was a problem hiding this comment.
I'm not sure I'm recalling it exactly, but the idea, especially in light of my proposal for a new rule checking for presentational roles conflict, was to encourage authors to address the presentational roles conflict issue first, rather than simply fixing the name. Once the original error is resolved, next steps can be considered.
I like your rewording suggestion and will apply it.
| 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. | ||
|
|
||
| ```html | ||
| <button role="none">submit</button> |
There was a problem hiding this comment.
I gather there are really two reasons why this button does not have a "computed" role of none: 1) confliction resolution's "element is focusable" clause, and 2) the fact that https://www.w3.org/TR/html-aria/#el-button , third column, does not contain the words "Any role". If I'm right about that, it means that this example is a little weirder than I think you meant it to be. But maybe it doesn't matter - I'll wait to see the outcome of my other comment on conflict resolution.
There was a problem hiding this comment.
Answered your question above. This example is just to clarify is not in scope for this rule.
There was a problem hiding this comment.
@giacomo-petri As discussed, I think we should compare this to existing rules to see which things this covers that we don't already have. We can then decide if we want to exclude those from this rule. Generally we've been trying to avoid overlap between rules - I think I'd prefer we do the same here.
Once we have the list we should put this on the agenda for discussion.
|
I've reviewed the following specifications to help the group better understand the WAI-ARIA direction and intent regarding the reduction of roles that require an acc name:
I compiled a list of all and only the roles that require an accessible name in at least one of these versions. For each role, I noted any changes, such as if it was not originally required but is now, or if it has since been removed from the requirement. In the final column, I included which of these roles are already covered by our rules, indicating whether we have specific test examples for them or if they are only applicable without associated examples.
I understand your concern, @WilcoFiers, about avoiding duplicates and minimizing secondary requirements. However, I don't see a straightforward way to categorize the remaining missed roles in a clean manner. For example, while many fall under non-operable controls, we are still missing roles like "tab" in other rules, so a category like "ARIA non-UIC" doesn't fully hold up. I'm inclined to suggest we keep it as is, accepting some overlap, given that ARIA roles inherently impact multiple rules. The alternative would be to explicitly list all the ARIA roles covered by this rule and justify why others were excluded in the background note. But IMO, that approach is more complex and harder for people to digest (and will probably require more maintenance over time). Open to your thoughts on this. |
|
Decision: Try to group roles in a meaningful way. Create rules for meaningful role groups. As a side effect, discuss the need for names of some of the roles. |
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