-
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
--enable-features=AutofillShowTypePredictions messes with accessibility results #11985
Comments
Could it be a side effect of lighthouse/lighthouse-cli/bin.js Line 119 in b2aa480
? |
Amazing, that's exactly what it is @brendankenny. When I launch Canary with |
Let's just remove the flag. If someone really wants to use the prediction part of this experimental audit, they can launch Chrome themselves. But we should not accept errors in core audits to keep this experiment going. Let's just hold out for the (upcoming ...) protocol api. sound good? |
Agreed, SGTM 👍 |
I've banged my head against this for too long, gotta call it a night, but happy to nerd snipe someone else if they're up for it 😅 Basically, Lighthouse running axe from CLI is returning different results (missing an
<input>
that lacks a label) than every other channel. PSI, DevTools, and evaluating the exact string that LighthouseevaluteAsync
s in the console all successfully find the label issue. The smoke test for the same axe rule is working just fine. I'm totally at a loss for what's going on at this point.Originally inspired by my failing FR CI test but this is a regular Lighthouse issue too. Can anyone else repro locally?
Provide the steps to reproduce
What is the current behavior?
Lighthouse marks "Form elements have associated labels" as passed.
What is the expected behavior?
Lighthouse marks "Form elements have associated labels" as failed.
Environment Information
The text was updated successfully, but these errors were encountered: