label-has-for rule should pass if containing nesting content about eslint-plugin-jsx-a11y

[acusti]

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 <label><input /> Form label text</label>.

The new rule could be something like label-has-form-control and would pass if it passes the label-has-for check OR if label has a single form element in its childNodes.

[ljharb]

I think an option to this rule called "required" that defaulted to ["nesting", "id"], had to be non-empty, and could be set to either one, or both, would be totally fine (as opposed to a separate rule).

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.

[acusti]

Adding an option that defaults to ["nesting", "id"] would be great!

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.

[jessebeach]

I think an option to this rule called "required" that defaulted to ["nesting", "id"], had to be non-empty, and could be set to either one, or both, would be totally fine (as opposed to a separate rule).

That's a great compromise. I'm running into violations of this as well. We use wrapping labels without an ID at FB.

[acusti]

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 required option that could be set to ["nesting"], thereby enabling people to use the rule without needing to use for/ID linking.

For my team, we’ve just decided to disable the rule until this option is available, so I’m looking forward to it landing.

[AlmeroSteyn]

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!

[vdh]

@ljharb @evcohen But why do assistive devices get a pass to break from the spec?

[josephg]

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.

[ljharb]

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.

[ignatiusreza]

Hi guys, sorry for jumping in.. I opened a PR at #240 for this..

[ljharb]

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.

[beefancohen]

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]

@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.

[vdh]

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.

[ljharb]

@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.

[vdh]

@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?

[ljharb]

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

[josephg]

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.

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.

[jessebeach]

I'm happy to review a PR if anyone wants to take a first-pass try at this.

[jessebeach]

If the test fails for the htmlFor attribute, then you'll want to check if the node and has one and only one child and let it pass if it does, fail it if not.

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.