-
Notifications
You must be signed in to change notification settings - Fork 23k
Provide more guidelines about labeling input #40548
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
fa88b9f
e4f6915
bf060cc
a2d2192
36bf6a7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -31,13 +31,45 @@ The **`<label>`** [HTML](/en-US/docs/Web/HTML) element represents a caption for | |||||
| } | ||||||
| ``` | ||||||
|
|
||||||
| ## Attributes | ||||||
|
|
||||||
| This element includes the [global attributes](/en-US/docs/Web/HTML/Reference/Global_attributes). | ||||||
|
|
||||||
| - [`for`](/en-US/docs/Web/HTML/Reference/Attributes/for) | ||||||
| - : The value of the `for` attribute must be a single [`id`](/en-US/docs/Web/HTML/Reference/Global_attributes/id) for a [labelable](/en-US/docs/Web/HTML/Guides/Content_categories#labelable) form-related element in the same document as the `<label>` element. So, any given `label` element can be associated with only one form control. | ||||||
|
|
||||||
| > [!NOTE] | ||||||
| > To programmatically set the `for` attribute, use [`htmlFor`](/en-US/docs/Web/API/HTMLLabelElement/htmlFor). | ||||||
|
|
||||||
| The first element in the document with an `id` attribute matching the value of the `for` attribute is the _labeled control_ for this `label` element — if the element with that `id` is actually a [labelable element](https://html.spec.whatwg.org/multipage/forms.html#category-label). If it is _not_ a labelable element, then the `for` attribute has no effect. If there are other elements that also match the `id` value, later in the document, they are not considered. | ||||||
|
|
||||||
| Multiple `label` elements can be given the same value for their `for` attribute; doing so causes the associated form control (the form control that `for` value references) to have multiple labels. | ||||||
|
|
||||||
| > [!NOTE] | ||||||
| > A `<label>` element can have both a `for` attribute and a contained control element, as long as the `for` attribute points to the contained control element. | ||||||
Josh-Cena marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||
|
|
||||||
| ## Usage notes | ||||||
Josh-Cena marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
|
||||||
| ### Styling with CSS | ||||||
|
|
||||||
| There are no special styling considerations for `<label>` elements — structurally they are inline elements, and so can be styled in much the same way as a {{htmlelement("span")}} or {{htmlelement("a")}} element. You can apply styling to them in any way you want, as long as you don't cause the text to become difficult to read. | ||||||
Josh-Cena marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||
|
|
||||||
| ### Associating a label with a form control | ||||||
|
|
||||||
| Associating a `<label>` with a form control, such as {{htmlelement("input")}} or {{htmlelement("textarea")}} offers some major advantages: | ||||||
|
|
||||||
| - The label text is not only visually associated with its corresponding text input; it is programmatically associated with it too. This means that, for example, a screen reader will read out the label when the user is focused on the form input, making it easier for an assistive technology user to understand what data should be entered. | ||||||
| - When a user clicks or touches/taps a label, the browser passes the focus to its associated input (the resulting event is also raised for the input). That increased hit area for focusing the input provides an advantage to anyone trying to activate it — including those using a touch-screen device. | ||||||
|
|
||||||
| There are two ways to associate a `<label>` with a form control, commonly referred to as _explicit_ and _implicit_ association. | ||||||
|
|
||||||
| To explicitly associate a `<label>` element with an `<input>` element, you first need to add the `id` attribute to the `<input>` element. Next, you add the `for` attribute to the `<label>` element, where the value of `for` is the same as the `id` in the `<input>` element. | ||||||
|
|
||||||
| ```html | ||||||
| <label for="peas">Do you like peas?</label> | ||||||
Josh-Cena marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||
| <input type="checkbox" name="peas" id="peas" /> | ||||||
| ``` | ||||||
|
|
||||||
| Alternatively, you can nest the `<input>` directly inside the `<label>`, in which case the `for` and `id` attributes are not needed because the association is implicit: | ||||||
|
|
||||||
| ```html | ||||||
|
|
@@ -47,6 +79,14 @@ Alternatively, you can nest the `<input>` directly inside the `<label>`, in whic | |||||
| </label> | ||||||
| ``` | ||||||
|
|
||||||
| These two methods are equivalent in modern browsers. However, there are some other considerations: | ||||||
|
||||||
| 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Josh-Cena marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Josh-Cena marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
Josh-Cena marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Uh oh!
There was an error while loading. Please reload this page.