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

[ZebulanStanphill]

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]

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]

Do any assistive technologies actually still not support both methods?

[vhoyer]

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

[vhoyer]

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]

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 :thinking:

[ZebulanStanphill]

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]

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]

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

[AustinGil]

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]

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]

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

[aitelia]

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

[vhoyer]

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

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]

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