Eslint-plugin-jsx-a11y: false negative on `label-has-for`

[webdif]

I have a code like this:

<div>
  <input
    /* HTML */
    type={type}
    className="field-input"
    id={id}
    name={name}
    placeholder={placeholder}

    /* React */
    value={value}
    onChange={this.handleChange}
    onFocus={this.handleFocus}
  />
  <label
    className="field-label"
    htmlFor={id}
  >
    {placeholder}
  </label>
</div>

I have an error: Form label must have associated control (jsx-a11y/label-has-for), while there is a htmlFor property on the <label>.

[ljharb]

The input needs to be nested inside the label as well, to ensure full a11y device coverage.

Per the docs, you can configure it to allow either nesting or IDs, but the default and recommended config is "both".

[webdif]

Thanks for the explanation!

[selbekk]

@ljharb I'm sorry, do you have any documentation as to why you need to wrap your form control in a label, as well as specifying htmlFor?

As far as I could read from the spec, only implicit labels (some text `) is at risk of not being read. Note that this is only documented as not working in Internet Explorer 6 - is this really a browser we want to optimize for?

The spec also states that you should not wrap checkboxes and radio buttons in labels - they should be placed after the input element like so:

<input id="test" name="test" type="checkbox /> <label for="test">Test checkbox</label><br/>
<input id="test" name="test" type="radio/> <label for="test">Test radio button</label>

From the docs:

Note that the label is positioned after input elements of type="checkbox" and type="radio".

Is the docs out of date, or is this assumption of having both explicit and implicit labels based on some real world testing or something? I'd love to know!

(I know this comes off as a bit harsh, I hope you see that my intentions are good. Thanks for a great project - you've done more for web accessibility than anything else out there.)

[ljharb]

For one, Dragon (the latest version), which is modern speech a11y software, only understands for-ID linking.

Both should be done, full stop.

[selbekk]

I'm all for (pun intended) for-ID linking, but what use cases are there for label -> form element nesting? Looks like all cases can be covered with for-ID linking?

[ljharb]

Nesting is a good idea regardless, because it increases the size of the interaction target for the user.

I believe there are some devices where for-ID linking is unreliable, but I don't have resources off hand.

[selbekk]

Okay :) Thanks for giving me an answer on that - I've never really thought IDs were needed when nesting and the other way around. Nice to know!