-
-
Notifications
You must be signed in to change notification settings - Fork 628
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
label-has-for rule should pass if containing nesting content #51
Comments
The actual reality is that you need BOTH nesting and id/for linkage to cover 100% of assistive devices - so despite what the spec says, imo your example is not valid. |
I agree with @ljharb and I think there is value in being explicit with linkage, regardless. It doesn't cost much to add id/for even with nesting, and it adds value with a11y and readability. |
@ljharb @evcohen But why do assistive devices get a pass to break from the spec? |
@vdh it's not that they get a pass, it's that it's web dev - you have zero control over browsers and end-user devices. "Best practices" include what works best with actual devices - not what ignores reality and works best with idealism. |
I would suggest having a separate rule for people who are primarily concerned with the spec-compliant “95%” of assistive devices use case. Avoiding ids in a big app being worked on by a big team is ideal, and using a random hash function or uuid generator as a render-time id seems like a silly hack for associating a label with a form element, particularly when a valid solution for the majority (90+%) use case is as simple as The new rule could be something like |
I think an option to this rule called "required" that defaulted to However, I don't feel compelled to enable the people who are comfortable with excluding ANY nonzero portion of the population - that kind of goes against the entire spirit of an accessibility linter plugin. Either every human matters, or what are we even doing here. |
Adding an option that defaults to At the same time, I really appreciate your articulation of the spirit of this tool. It’s refreshing to hear such a principled and uncompromising approach to anything in web development. I think I’m realizing that at some point in the past 10 years, I gave up on aspirations to my own version of that goal in the face of the messy, non-standard world of the web, and settled for the 95% version. But maybe I can resurrect that ethos in my own work, or at least reconsider it as in the realm of possibility. |
While I applaud the desire to support 100% of people, especially for an audience who may not be readily able to update or replace these devices as often as mainstream browsers, it bothers me that manufacturers are able to essentially use developers concerned about accessibility as an easy out when delivering a lacklustre product. Is there any further documentation about these non-standard inconsistencies between assistive devices? It might be good to find out which manufacturer is doing which non-standard behaviours. |
@vdh I'm not aware of any modern/current devices that don't follow the proper specs, but my understanding is that there are a number of older devices still in circulation, like older browsers, that don't conform. |
@ljharb That makes sense. So do you know of any sites out there documenting these devices still in circulation? Similar to how caniuse.com tracks current browser circulation? |
I'm not aware of anything like that, but I'd love to learn about it :-) Either way, when it's not difficult to cover 100%, there's no good reason not to do so :-) |
I admire the spirit, but can somebody please name a single device which fails to comply with the spec regarding nesting labels? If not, this seems ridiculous. I roll to disbelieve - and I'm not going to make my / my team's code more awkward to write as a result. |
http://usability.com.au/2008/09/accessible-forms-using-wcag-2-0/ is an old standard but does mandate for/ID linking. I don't have that information off the top of my head, but if you don't believe in the spirit of the rule, just turn it off. |
That tech report is from 8 years ago. IE8 wouldn't be released for another year. I mean, IE6 still ruled the roost with ~50%+ browser usage iirc. If we're aiming for compatibility with devices that haven't been updated in 8 years, forget input labels - we need to replace all these transparent PNGs! Tech report or no, my bar is still the same. Name a single device thats still in use but not spec compliant in this regard. |
Based on @evcohen’s https://github.com/evcohen/eslint-plugin-jsx-a11y/issues/84#issuecomment-244376916, seems like the particulars of finding a device / browser in use that requires for/ID linking is moot, because the plan is to implement a For my team, we’ve just decided to disable the rule until this option is available, so I’m looking forward to it landing. |
That's a great compromise. I'm running into violations of this as well. We use wrapping labels without an ID at FB. |
Also ran into this today. Created a duplicate issue before seeing this one. Being able to nest would be great. Nested inputs take away a lot of overhead creating and managing system generated IDs in React. Allowing to configure the rule to allow nesting is a great idea! |
I'm happy to review a PR if anyone wants to take a first-pass try at this. |
If the test fails for the https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/master/src/rules/label-has-for.js#L25 We might want to break this out into its own rule, but this is a good place to start to validate the approach. |
Hi guys, sorry for jumping in.. I opened a PR at #240 for this.. |
I am getting hit by the "label-has-for" rule in my code. It appears that every label is required to have an "htmlFor" that matches an ID for an element on the page, but I believe that this should be valid:
According to this: https://www.w3.org/TR/html401/interact/forms.html#edef-LABEL
Referring to the for attribute: "When present, the value of this attribute must be the same as the value of the id attribute of some other control in the same document. When absent, the label being defined is associated with the element's contents."
The main hiccup I can think of is if you have multiple elements inside a label.
The text was updated successfully, but these errors were encountered: