eslint-plugin-jsx-a11y: label-has-associated-control error with label/input
I believe I’m seeing an issue with the following snippet on eslint-plugin-jsx-a11y 6.2.3. I believe we’re going to disable the rule for now and just re-enable after it gets resolved.
<div className="field">
<label htmlFor="nameInput" className="label">Name</label>
<div className="control has-icons-left">
<input
id="nameInput"
className="input"
disabled={isPosting}
type="text"
name="name"
placeholder="How should we address you"
value={name}
onChange={this.onChange}
/>
<span className="icon is-small is-left">
<i className="fas fa-tag" />
</span>
</div>
</div>
Output from the run config appears that this case should be covered and function properly via the documentation and conversation in another issue I initially read as identical. From what I’m seeing in the output the depth here is 25 so I’m confused as why this is not working as I believe it should.
ESLint run output snippet:
/[path]/src/screens/RegisterScreen.jsx
153:13 error A form label must be associated with a control jsx-a11y/label-has-associated-control
172:13 error A form label must be associated with a control jsx-a11y/label-has-associated-control
193:13 error A form label must be associated with a control jsx-a11y/label-has-associated-control
213:13 error A form label must be associated with a control jsx-a11y/label-has-associated-control
Relevant snippet from eslint run rules:
"jsx-a11y/label-has-associated-control": [
"error",
{
"labelComponents": [],
"labelAttributes": [],
"controlComponents": [],
"assert": "both",
"depth": 25
}
],
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 15 (6 by maintainers)
The “both” assert means that the input has to also be inside the label. If you change it to “either” or “htmlFor”, it will permit your example.
Sorry, you’re right; i meant vision-impaired. My mistake.
That many websites do a poor job of accessibility highlights why it’s so important to maintain high standards - it’s not an excuse for lax ones.
If my personal axe is “not excluding human beings”, then you’re right 😃
Supporting old devices/platforms is critical for those that can’t update. Not supporting them is hostile. Nobody’s using an old platform because they want to. As for non-compliance, again, hurting people isn’t a just way to force a corporation to change.
Adding both nesting and for-ID linking isn’t a large cost. Airbnb has 30,000+ react components (as of last July) and all form controls use this approach.
There is nobody still using IE 6 because it can’t even connect to SSL anymore. You should be supporting IE 9, ideally, but that depends on your demographic’s usage. The difference here is that a hearing-impaired user on modern Chrome will still be screwed if you don’t follow this recommendation - why are you advocating to discriminate against them? (note that US law also allows massive financial penalties in civil court for discriminating against protected classes, and this exact category already applies, per court precedent)
@ljharb You sir are a rockstar! I apologize for creating a bit of distraction on the other issue. Switching from “both” to “either” knocked it right out. For anyone who may stumble here and is also using the yml format:
I would, however, suggest nesting the input inside the label, since doing both covers more assistive devices and allows the maximal amount of people to use the input properly.
Seems not working when you use
styled-componentany ideas?It’s also worth noting that I have checked the websites of several accessible browsers and none of them follow this recommendation themselves.
Check out …
Having the same issue with
styled-component.I didn’t realise that hearing had anything to do with ability to read or use a website form?
I’m not advocating or discriminating against anyone. I’m stating that standards exist to allow companies and developers to provide for these types of people in a way that is economically and technically viable for smaller businesses that can’t spend millions on developers.
By enforcing your very narrow view all that will happen is that those companies and their developers will, at best, simply ignore the warnings your package throws up and at worst, remove the package or disable it.
Rather than fighting a crusade that will lead to the opposite of your intended goal, why not work with the established standards and use your knowledge and influence to work with the people defining the standards to improve them. Likewise, working with the developers of assistive technology to help them to better adhere to those standards.
The web became a better place, both for users and for developers when the W3C was formed and browser vendors started working together to produce comparable user experiences across different devices and browsers. Why should assistive tech be any different?