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

Add generic audit for accessible names #11155

Closed
eps1lon opened this issue Jul 24, 2020 · 6 comments
Closed

Add generic audit for accessible names #11155

eps1lon opened this issue Jul 24, 2020 · 6 comments

Comments

@eps1lon
Copy link

eps1lon commented Jul 24, 2020

Provide a basic description of the audit

Audit if roles that require an accessible name have one (e.g. dialog or tree)

How would the audit appear in the report?

title: Elements have an accessible name
failureTitle: Elements do not have an accessible name
description: When a $ROLE_NAME_HERE does not have an accessible name screen readers announce it with a generic name, making it unusable for users who rely on screen readers.

The documentation should distill https://www.w3.org/TR/wai-aria-practices-1.1/#name_calculation into a format that applies on a per-role basis. The original section is quite complex.

How is this audit different from existing ones?

  • button-name only warns on buttons
  • label only on form controls

Though I suspect both just check for existence of the accessible name.

What % of developers/pages will this impact?

I can't make an estimate. Some roles with accessible name required are probably more common (dialog) while more complex widgets are likely rarer (such as tree)

How is the new audit making a better web for end users?

People using screen readers get a more meaningful announcement when navigating e.g. dialog or tree.

What is the resourcing situation?

Would like to help. I guess the biggest problem is that this new rule doesn't interfere with existing naming audits so that users don't get flooded with redundant errors.

Though it might be better to add audits/docs for each role instead.

Any other links or documentation that we should check out?

@patrickhulce
Copy link
Collaborator

Thanks for filing @eps1lon! This sounds like a great candidate for axe-core which is what Lighthouse uses under the hood. Have you already discussed it with that team? I'm sure they'd be able to shed more light on where this is in their roadmap, if they've considered it before, etc :)

@eps1lon
Copy link
Author

eps1lon commented Jul 27, 2020

This sounds like a great candidate for axe-core which is what Lighthouse uses under the hood. Have you already discussed it with that team?

Tracked in dequelabs/axe-core#2421

@eps1lon
Copy link
Author

eps1lon commented Nov 16, 2020

This sounds like a great candidate for axe-core which is what Lighthouse uses under the hood. Have you already discussed it with that team?

Tracked in dequelabs/axe-core#2421

Can be closed once lighthouse uses axe-core@^4.1.0.

@connorjclark
Copy link
Collaborator

Dedupe #11207. watch #11661 for updates.

@patrickhulce
Copy link
Collaborator

patrickhulce commented Nov 16, 2020

@connorjclark #11661 doesn't add the new audits for new rules in axe, so maybe we should leave this open instead of deduping? just saw the comment mentioning this #11661 (comment) :) still leave this open to be closed by that PR?

Thanks for following up @eps1lon!

@connorjclark
Copy link
Collaborator

I'm adding them now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants