-
-
Notifications
You must be signed in to change notification settings - Fork 28
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
Comments
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? |
Do any assistive technologies actually still not support both methods? |
I don't know, do you know how to check? 😅 is there a caniuse AT version? 😅 this would be nice |
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). |
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 🤔 |
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, It seems that the only lack of support that ever existed was for implicit labels, and explicit labels (i.e. using |
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) |
Yeah, I'm suggesting we change the default configuration. |
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 ;) |
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. |
Yeah, good catch. I should have said that everything that supports implicit labels supports explicit labels, but the opposite is not true. |
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 |
@vhoyer yes, workaround did help. Hope this gets fixed sometime in future. |
eslint-plugin-jsx-a11y
'slabel-has-for
has recently been deprecated and replaced bylabel-has-associated-control
. This plugin should probably follow suit. I find the default behavior oflabel-has-for
to be confusing, since using both wrapping and afor
attribute is redundant. (And for styling reasons, it is often not desirable to wrap<input>
s with<label>
s.)The text was updated successfully, but these errors were encountered: