Provide more guidelines about labeling input #40548
Conversation
github-actions
bot
added
Content:HTML
|
Preview URLs External URLs (1)URL:
(comment last updated: 2025-08-04 15:10:07) |
| </label> | ||
| ``` | ||
|
|
||
| These two methods are equivalent in modern browsers. However, there are some other considerations: |
There was a problem hiding this comment.
| These two methods are equivalent in modern browsers. However, there are some other considerations: | |
| These two methods are equivalent, but there are a few considerations: |
There was a problem hiding this comment.
IMO "in modern browsers" is important. (1) Legacy browsers are generally irrelevant, but we are talking about a11y anyway, and supporting more browsers is part of a11y; (2) We talk about non-browser consumers of the HTML, so mentioning "browsers" is also important, otherwise saying "they are functionally equivalent, except in certain cases they are not functionally equivalent" is weird.
| These two methods are equivalent in modern browsers. However, there are some other considerations: | ||
|
|
||
| - Not all assistive technologies support implicit association. | ||
| - Implicit association may be harder to style because the label box contains the form control instead of being separate elements. |
There was a problem hiding this comment.
could also be easier to style. maybe something like this:
| - Implicit association may be harder to style because the label box contains the form control instead of being separate elements. | |
| - Depending on your design, the type of association may impact the stylability; with an implicit association, the control is nested ensuring the visual association, while explicit associations enable the label and form controls to be adjacent, enabling lining up the elements with grid or flex layout methods. |
There is little inheritance with form controls, so that's not an issue. I assume that the design issue is that flex and grid can't be used. There used to be an issue in IE6 or 7, which I blogged about over 15 years ago, where the browser divided the implicit label into two elements, causing duplicated backgrounds and causing borders to close and reopen, but that is old news.
There was a problem hiding this comment.
I was thinking about, for example, the label and the input being visually separate, in which case having a nested box means you have a box straddling between them that pushes everything else away. Sort of a weird headache I run into often.
|
|
||
| - Not all assistive technologies support implicit association. | ||
| - Implicit association may be harder to style because the label box contains the form control instead of being separate elements. | ||
| - When using component frameworks with explicit association, it's often hard to ensure that the control has a globally unique `id` (React introduced the [`useId()`](https://react.dev/reference/react/useId) hook for this purpose). |
There was a problem hiding this comment.
hesitant to include this as IDs should always be unique and adding react's fix is like saying they're a little less shitty than other options. Maybe something like:
| - When using component frameworks with explicit association, it's often hard to ensure that the control has a globally unique `id` (React introduced the [`useId()`](https://react.dev/reference/react/useId) hook for this purpose). | |
| - Implicit labels do not require a form control to have an `id`. Every `id` in a document should be unique. However, some component frameworks may not ensure every form control has a unique `id`. While this is bad in general, it can make the resulting output inaccessible. |
There was a problem hiding this comment.
It's straight out invalid HTML and should be treated as a syntax error, which is worse than "inaccessible", so I was phrasing it as a first principle that IDs must be unique. The point is how we mitigate such issues for framework users (which represent 99% of developers), and I'm providing React as an example, which probably represents 50%+ of our readers.
| - Implicit association may be harder to style because the label box contains the form control instead of being separate elements. | ||
| - When using component frameworks with explicit association, it's often hard to ensure that the control has a globally unique `id` (React introduced the [`useId()`](https://react.dev/reference/react/useId) hook for this purpose). | ||
|
|
||
| Generally, we recommend using explicit association with the `for` attribute, to ensure compatibility with external tools and assistive technologies. In fact, you can simultaneously nest _and_ provide `id`/`for` for maximum compatibility. |
There was a problem hiding this comment.
| Generally, we recommend using explicit association with the `for` attribute, to ensure compatibility with external tools and assistive technologies. In fact, you can simultaneously nest _and_ provide `id`/`for` for maximum compatibility. | |
| It is considered a best practice to explicitly associate every `<label>` with a form control using the `for` attribute even if that form control is nested within the `<label>. |
There was a problem hiding this comment.
I don't think it's universally considered a best practice due to the third point about unique IDs; it's just our own recommendation
There was a problem hiding this comment.
i don't think "we" should "recommend" stuff, especially if we don't officially have a meeting to decide we're making a recommendation.
There was a problem hiding this comment.
We do recommend things all the time though. For example we say "don't use eval()", or "prefer rgb() to rgba()", or "use Temporal instead of Date". In this case the reasoning is well-founded (explicit association has more support). Remember that not all ATs are full HTML implementations and they are not required to be.
| - Implicit association may be harder to style because the label box contains the form control instead of being separate elements. | ||
| - When using component frameworks with explicit association, it's often hard to ensure that the control has a globally unique `id` (React introduced the [`useId()`](https://react.dev/reference/react/useId) hook for this purpose). | ||
|
|
||
| Generally, we recommend using explicit association with the `for` attribute, to ensure compatibility with external tools and assistive technologies. In fact, you can simultaneously nest _and_ provide `id`/`for` for maximum compatibility. |
There was a problem hiding this comment.
i don't think "we" should "recommend" stuff, especially if we don't officially have a meeting to decide we're making a recommendation.
| ``` | ||
|
|
||
| > [!NOTE] | ||
| > It is a good practice to place any necessary context, such as the link to the terms and conditions, before the form control, so that the user can read it before they interact with the control. |
There was a problem hiding this comment.
not the norm for radio and checkboxes. https://www.w3.org/TR/WCAG20-TECHS/G162.html#G162-description, and we just did the opposite 5 lines before
There was a problem hiding this comment.
The associated label can be thought of as "parallel" to the control and their order is irrelevant to screen reader because they are announced together. What I'm saying here is that you should have the ToC link above the label-control pair instead of below them, so screen reader users can reach them in the intended order
| ### Headings | ||
|
|
||
| Placing [heading elements](/en-US/docs/Web/HTML/Reference/Elements/Heading_Elements) within a `<label>` interferes with many kinds of assistive technology, because headings are commonly used as [a navigation aid](/en-US/docs/Web/HTML/Reference/Elements/Heading_Elements#navigation). If the label's text needs to be adjusted visually, use CSS classes applied to the `<label>` element instead. |
There was a problem hiding this comment.
the next line talkes about legend and fieldset, but the example-good doesn't include them. this needs work too. not sure if you want to add to this PR.
Co-authored-by: Estelle Weyl <[email protected]>
Fix #37665, and its two linked issues, which as I work through this PR realized are not actually duplicates of #37665.