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

Replace label-has-for with label-has-associated-control (to match eslint-plugin-jsx-a11y) #54

Open
ZebulanStanphill opened this issue Aug 27, 2020 · 14 comments
Labels
good first issue Good for newcomers

Comments

@ZebulanStanphill
Copy link

eslint-plugin-jsx-a11y's label-has-for has recently been deprecated and replaced by label-has-associated-control. This plugin should probably follow suit. I find the default behavior of label-has-for to be confusing, since using both wrapping and a for attribute is redundant. (And for styling reasons, it is often not desirable to wrap <input>s with <label>s.)

@vhoyer
Copy link
Collaborator

vhoyer commented Aug 27, 2020

but how about this line in the doc: https://github.com/vue-a11y/eslint-plugin-vuejs-accessibility/blame/master/docs/label-has-for.md#L8

is it really safe for all assistive technologies to use only one of them?

@ZebulanStanphill
Copy link
Author

Do any assistive technologies actually still not support both methods?

@vhoyer
Copy link
Collaborator

vhoyer commented Aug 27, 2020

I don't know, do you know how to check? 😅 is there a caniuse AT version? 😅 this would be nice

@vhoyer
Copy link
Collaborator

vhoyer commented Aug 27, 2020

I found this: https://a11ysupport.io/tech/html/label_element (it seems a really cool site), and there are reports of the implicity relationship between the label and the control element that are not working correctly (mainly on voice control).

@vhoyer
Copy link
Collaborator

vhoyer commented Aug 27, 2020

But they are old (one to two years, for what I read), and I don't know how to test them to update the data 🤔

@ZebulanStanphill
Copy link
Author

I also did some research, and found this document from 2008, which states that "some assistive technologies do not correctly handle implicit labels (for example, <label>First name <input type="text" name="firstname"></label>)". The modern equivalent simply recommends the usage of explicit labels... never even mentioning implicit labels.

It seems that the only lack of support that ever existed was for implicit labels, and explicit labels (i.e. using for) have always been well-supported and/or recommended. With that in mind, it seems like we should update the rule to at least not complain about explicit <label>s. There seems to be no accessibility advantage to using <label> as a wrapper if you've already given it a for attribute. The rule could still complain about <label>s without fors, of course.

@vhoyer
Copy link
Collaborator

vhoyer commented Aug 28, 2020

Nice resource, are you suggesting we change the default configuration of the rule? because currently we as user can change de "requireness" of nesting 🤔 (not a maintainer here)

@ZebulanStanphill
Copy link
Author

Yeah, I'm suggesting we change the default configuration.

@AustinGil
Copy link

I wrote an article on accessible form elements recently (https://austingil.com/how-to-build-html-forms-right-accessibility/) and my research aligns with some of the comments stated above. Implicit labels are supported by most AT, but not all. As far as I could find, explicit labels are supported by all, or I didn't find anything stating the contrary.

In my opinion, enforcing explicit labels via ID should be the default requirement, but using a wrapping label should not be (although users can opt-in). The reason is that by setting a more strict default, more users will encounter errors (possibly leading to more issues here), and it restricts the markup options for users. In some cases, it's not possible to wrap an input with it's respective label because they are actually quite far apart. On the other hand, I'm not sure I see any benefit from enforcing labels wrap inputs as the default setting. I don't believe label+ID is any more accessible than just ID, but I reserve my right to be wrong ;)

@vhoyer
Copy link
Collaborator

vhoyer commented Apr 26, 2021

explicit labels are supported by all

Hmm, I'd just like to point out that this link: https://a11ysupport.io/tech/html/label_element, suggests that explicit label do not work with voice access on android, that said neither does implicit label.

@AustinGil
Copy link

Yeah, good catch. I should have said that everything that supports implicit labels supports explicit labels, but the opposite is not true.

@aitelia
Copy link

aitelia commented Apr 28, 2022

This is still not working in "eslint-plugin-vuejs-accessibility": "1.1.1". Any updates on the solution to fix this false positive issue?

Screenshot 2022-04-28 at 11 42 47

@vhoyer
Copy link
Collaborator

vhoyer commented Apr 28, 2022

This is still not working in "eslint-plugin-vuejs-accessibility": "1.1.1". Any updates on the solution to fix this false positive issue?

Screenshot 2022-04-28 at 11 42 47

Well, @aitelia, you could very well open a PR to update the rule name and the default configuration to just check for explicitly labels instead of enforcing wrapping+id, but be aware that you as an user can fix this issue for yourself on your project just by updating the rule definition as stated on #119

@aitelia
Copy link

aitelia commented Apr 28, 2022

@vhoyer yes, workaround did help. Hope this gets fixed sometime in future.

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

No branches or pull requests

4 participants