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

--enable-features=AutofillShowTypePredictions messes with accessibility results #11985

Closed
patrickhulce opened this issue Jan 21, 2021 · 4 comments · Fixed by #12038
Closed

--enable-features=AutofillShowTypePredictions messes with accessibility results #11985

patrickhulce opened this issue Jan 21, 2021 · 4 comments · Fixed by #12038
Labels

Comments

@patrickhulce
Copy link
Collaborator

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 Lighthouse evaluteAsyncs 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

  1. Run LH on http://melodic-class.glitch.me/axe-label.html

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

  • Affected Channels: CLI only (AFAICT)
  • Lighthouse version: master
  • Chrome version: Canary and stable
  • Node.js version: v12
  • Operating System: macOS + Linux
@brendankenny
Copy link
Member

Could it be a side effect of

cliFlags.chromeFlags.push('--enable-features=AutofillShowTypePredictions');

?

@patrickhulce
Copy link
Collaborator Author

patrickhulce commented Jan 21, 2021

Amazing, that's exactly what it is @brendankenny. When I launch Canary with --enable-features=AutofillShowTypePredictions the audit (incorrectly) passes in DevTools as well.

@patrickhulce patrickhulce changed the title CLI Axe results are different from other channels on simple form input --enable-features=AutofillShowTypePredictions messes with accessibility results Jan 21, 2021
@connorjclark
Copy link
Collaborator

connorjclark commented Feb 1, 2021

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?

@patrickhulce
Copy link
Collaborator Author

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 👍

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

Successfully merging a pull request may close this issue.

4 participants