-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
Handle accessibility incomplete and violations simultaneously #14354
Comments
Thanks for reporting this and doing an investigation! Not very often that someone reports a page that should be failing an audit but isn't. Your analysis is correct. The failure is hidden by this line:
The audit is not classified as informative so we ignore any |
ref: |
FYI I’ve opened #14438 and #14439, which are the same issue as this as far as I can tell, just with different audits. Feel free to close those if it’s better to handle all three problematic audits at once. Those are the only three audits where I suspected this issue. I spotted this as part of the Accessibility chapter of the HTTP Archive’s Web Almanac, where we review Lighthouse audit scores across 8M websites. Those 3 audits are the only ones that run on hundreds of thousands / millions of pages, and didn’t report a single failure. Here is the Lighthouse audit data if anyone wants to spend more time looking, and our SQL query (BigQuery). |
Thanks for the research @thibaudcolas! I think should merge everything into this audit, but good to know which audits this problem affects. |
or (if possible for incomplete and violations to both occur)
|
to rationalize the whole axe informative behavior, start with thread here: #12536 (comment) |
bypass
accessibility audit always shows as passing even in error scenarios
FAQ
[ ] Yes, my issue is not about a specific accessibility audit (file with axe-core instead).URL
https://accessibility-experiments-90d5b5.netlify.app/lighthouse-bypass-audit/index.html
What happened?
The
bypass
audit based on Axe’s bypass rule always shows as passing when it’s applicable, even when there are issues on the page that Axe itself detects.Sample page: https://accessibility-experiments-90d5b5.netlify.app/lighthouse-bypass-audit/index.html
Lighthouse results for bypass on this page (JSON export)
Axe CLI results for the same page
Command:
axe -r bypass https://accessibility-experiments-90d5b5.netlify.app/lighthouse-bypass-audit/index.html --save bypass.json && cat bypass.json
Output:
What did you expect?
Lighthouse’s results for
bypass
should be consistent with those of Axe. In this instance, Axe reportsbypass
as "incomplete", so it shouldn’t be a pass with Lighthouse. I would have expected either a "Additional items to manually check", or an error.What have you tried?
I’ve investigated how the Axe rule works, and suspect the issue is due to Axe changing the output of this rule from
violations
toincomplete
. This apparently happened in Axe v4.2 because although the rule can detect the absence of "bypass" functionality, it can’t detect whether there is actually anything to bypass on a page.I suspect the issue in Lighthouse is in the Axe audit processing logic, around here, where Axe handles incomplete results differently based on the audit’s display mode:
lighthouse/core/audits/accessibility/axe-audit.js
Lines 47 to 58 in fd304ed
I’m unclear whether the current logic could work or whether there needs to be additions here.
How were you running Lighthouse?
Chrome DevTools, web.dev
Lighthouse Version
9.6.6
Chrome Version
107
Node Version
No response
OS
Mac
Relevant log output
No response
The text was updated successfully, but these errors were encountered: