-
Notifications
You must be signed in to change notification settings - Fork 9.6k
core(scoring): adjust a11y weights and document approach #16624
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
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
816c5e3 to
5c11b1c
Compare
5c11b1c to
6aa5e98
Compare
|
Greetings @connorjclark. I'm sure you are busy, but I want to make sure this PR doesn't slowly fade into oblivion 😄 Let me know if there is anything I can do to answer any questions or help make reviewing these changes easier for you or your team. |
|
If I understand correctly: currently we weigh the a11y audits based on each axe rule's severity (that should be pretty consistent, but it's possible severity of some rules may have changed without us noticing). And your proposal is to additionally not score an audit if the severity is minor and merely a "best practice", ie. not in wcag (weight: 1 -> 0) – but otherwise, we treat "deque best practice rules" the same as rules backed by wcag. Is that correct? If so, I think that would be a good change. Could you help me understand the actual delta in audit weights? I'm having trouble telling by just looking at the diff. We can't make scoring changes w/o a breaking release, but there will be one in October. |
@connorjclark Yes. Your summary is correct 👍
@connorjclark Agreed, this will affect scoring changes. I've created a branch to make the For easier diffing It adjusts
I've also summarized the changes in this screenshot. Please note, in the screenshot, I have also added an additional question. The TLDR is: What do you think about the values I have chosen for Deque 'best-practices' audits? I'm open to suggestions, adjustments, and discussions. Many thanks for taking a look at this 🙇
|
|
Greetings @connorjclark, just wanted to make sure you saw my previous comment. Thanks! |
|
I think we should continue weighing best-practice checks that are not Minor. I want to keep deferring to Deque's expertise, but raising the bar a tiny bit to omit the minor ones feels alright to me. Whether they are equal to the wcag one is a bit more subjective. I could see us down-shifting the rubric for best-practices (minor: 0, moderate: 1, Serious: 3, Critical: 7). I'll ask around internally. Thanks for producing #16667. FYI, it there may be a few weeks until this is accepted, but I don't think we'll require any additional work from your end. Thanks for taking the time to make this proposal. EDIT: @paulirish and I quickly settled on just doing what you have in your PR (minor + best-practices = 0), not the "down-shifting" thing I mentioned above. Had no strong reason to choose one over the other, so we preferred the smaller change. |
|
@connorjclark sounds great. let me know if there is anything else you need from me and many thanks for taking the time to review 🙇 |
|
Thanks Ben! |

Summary
This is a change (and proposal/discussion) to implement a consistent way to weight accessibility audits.
Describe the need for this change
As part of my ongoing tracking of lighthouse a11y scores, I've been noticing that occasionally, my scores fluctuate from 100 to 99 because of the
aria-allowed-roleaudit.When I look at the Deque documentation for this audit, I notice that is NOT tagged as part of wcag, but is only tagged as a Deque best-practice. Additionally, it is marked as User Impact: Minor.
You can see my proposal in my comments in the default-config.js:
I also want to call out the sections at the bottom that I have adjusted:
Callout: We may want to include a bit more wiggle room than the strict rules I have proposed. If that is the case, I think that too should be documented to help people understand why certain rules are weighted in one way vs another.
Related Issues/PRs
w3c/html-aria#543 is a proposal to adjust textarea elements to allow role="combobox."
It is related because this is what I am getting flagged for using. This is consistent with the approach that google uses for their main search box and from my testing it works well across browser and across screen reader.