Eslint-plugin-jsx-a11y: Labels wrapped around textarea report label-has-associated-control lint error

[davidwkeith]

Example

I also see the issue with:

• <label>foo<meter /></label>
• <label>foo<output /></label>
• <label>foo<progress /></label>

Workaround
Add the following to your .eslintrc.js

module.exports = { rules:
    'jsx-a11y/label-has-associated-control': [`error`, {controlComponents:[ 'textarea', 'meter', 'output', 'progress' ]}],
}

[guoyunhe]

I have same issue with input. No matter it is wrapped input or referenced input.

[ljharb]

@guoyunhe you need to both wrap and for-ID link, by default.

[guoyunhe]

@ljharb but the document says you don't need id when wrapping it:

This rule checks that any label tag (or an indicated custom component that will output a label tag) either (1) wraps an input element (or an indicated custom component that will output an input tag) or (2) has an htmlFor attribute and that the label tag has text content.

[ljharb]

Fair point. That seems strange, then (altho i think the default should be "both" not "either")

[guoyunhe]

Is here any reason to enforce "both"?

From https://a11yproject.com/checklist/#section-forms

Use a for/id pairing to guarantee the highest level of browser/assistive technology support.

It doesn't say both.

For screen readers, they can understand either way of label-input connection. Doing both doesn't make it better for end users but add a lot of inconveniences to developers.

[ljharb]

Yes - there are some things that only work with nesting (many assistive devices), and others that only work with for-ID linking (Dragon, for example). Doing both gives you 100% a11y coverage, which definitely makes things easier for developers, whose inconvenience is irrelevant compared to users' accessibility :-)

[davidwkeith]

@ljharb that is news to me. Then both should be required for all label-able elements. (and a good chance to write a blog post on how to best generate IDs for JSX components without using UUIDs)

[guoyunhe]

We need to see evidece. The web is about standard. ID linking is a standard. We shouldn't force developers to support non-standard devices. Wrapping is sometimes impossible if you use some UI library. If it has to be both, there should have been enough evidence in the document.

[jessebeach]

I'm going to maintain the option in the rule to account for one, the other,
or both.

On Tue, Nov 5, 2019 at 12:05 AM Guo Yunhe [e-mail] wrote:

We need to see evidece. The web is about standard. ID linking is a
standard. We shouldn't force developers to support non-standard devices.
Wrapping is sometimes impossible if you use some UI library. If it has to
be both, there should have been enough evidence in the document.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/evcohen/eslint-plugin-jsx-a11y/issues/639?email_source=notifications&email_token=AACUOOPFJ7J5WPJWBXLKA43QSESM5A5CNFSM4I6JCCPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDB6F6I#issuecomment-549708537,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACUOOLEBHKHFJDYL2YKGWDQSESM5ANCNFSM4I6JCCPA
.

[ljharb]

@guoyunhe Dragon, specifically, does not support nesting. You're welcome to try it yourself.

Separately, accessibility is not about standards, it is about actual users being able to use websites, which only depends on what browsers and devices do - we hope that matches the standard, but if it doesn't, then the standard is irrelevant.

[guoyunhe]

The assert: both option is actually enforced by eslint-config-airbnb package. If you use directly eslint-plugin-jsx-a11y, you shouldn't have this issue. But if you use it with eslint-config-airbnb, you will have the trouble.

[ljharb]

With both the airbnb config, and with using it directly, you can configure the rule however you like - but the goal here is accessibility for everyone, and "both" is the only setting that ensures that.

[jessebeach]

Thank you all for the report and details. #710 should fix this issue.