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

Browser extension: axe is ignoring hidden labels for input fields even when it should acknowledge them #1176

Closed
chirag64 opened this issue Oct 4, 2018 · 7 comments
Assignees
Labels
fix Bug fixes rules Issue or false result from an axe-core rule

Comments

@chirag64
Copy link

chirag64 commented Oct 4, 2018

There are common instances where we often require labels of input fields to be hidden (e.g. Search box because it already has a search icon in it).

As per this W3C article, the recommended way to achieve this is to add the below CSS code to the label:

.visuallyhidden {
  border: 0;
  clip: rect(0 0 0 0);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  width: 1px;
}

But even after implementing this, aXe still throws an error for the field saying Form elements must have labels.

Here is a working demo of the same: https://jsfiddle.net/xk2vaq6f/1/embedded/result

@Volker-E
Copy link

Volker-E commented Oct 9, 2018

Same issue at https://wikimediafoundation.org/ on element input#wmf-subscribe-input-email. First idea was that clip: rect( 1px 1px 1px 1px ) would be needed to not count as 'hidden'. But changing didn't resolve error output.

@chirag64
Copy link
Author

chirag64 commented Oct 9, 2018

Same issue at https://wikimediafoundation.org/ on element input#wmf-subscribe-input-email. First idea was that clip: rect( 1px 1px 1px 1px ) would be needed to not count as 'hidden'. But changing didn't resolve error output.

Right, clipping does seem to be the problem. Even if you use large values like 100px with it, it does not resolve the issue, which means axe does not bother checking for its values.

@WilcoFiers
Copy link
Contributor

WilcoFiers commented Oct 9, 2018

Interestingly, that's the exact same bug I reported at almost the same time as you. #1177. I'll close that one as a duplicate.

@WilcoFiers WilcoFiers added the fix Bug fixes label Oct 9, 2018
chirag64 added a commit to chirag64/axe-core that referenced this issue Oct 9, 2018
… 0px in all directions

    Instead of marking all clipped labels as hidden, we're now checking their values as well

    Closes issue: dequelabs#1176
@chirag64
Copy link
Author

chirag64 commented Oct 9, 2018

Have submitted a PR for this. Please let me know if I've missed something as per project guidelines, I'll happily fix it

@stephenmathieson stephenmathieson self-assigned this Oct 10, 2018
@WilcoFiers WilcoFiers added the rules Issue or false result from an axe-core rule label Oct 18, 2018
stephenmathieson added a commit that referenced this issue Oct 22, 2018
* fix: consider element's accessible names when labels are hidden

Closes #1176

* chore: revert condition for pr review

* chore: update to use `isVisble` sr mode
@chirag64
Copy link
Author

chirag64 commented Nov 2, 2018

Any idea when this fix will be available in the stable versions of the Chrome & Firefox extensions? We've a defect open on our system that has a dependency on this. 😓

@calder12
Copy link

This is still an issue, Using Lighthouse v4 shows elements using the CSS in the initial report as "Form element has explicit that is hidden" Using Lighthouse v 3.2.0 (which uses axe-core 3.0.0 beta) correctly identifies the labels.

Any idea on a resolution time for this?

@nolanlawson
Copy link

This still appears to be happening in axe Chrome extension v3.7.0. The <label> I'm using has the following styles:

.sr-only {
    position: absolute;
    width: 1px;
    height: 1px;
    padding: 0;
    margin: -1px;
    overflow: hidden;
    clip: rect(0, 0, 0, 0);
    border: 0;
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fix Bug fixes rules Issue or false result from an axe-core rule
Projects
None yet
Development

No branches or pull requests

6 participants