Skip to content
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
72 changes: 47 additions & 25 deletions files/en-us/web/html/reference/elements/label/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

## Usage notes

### 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.

### 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>
<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
Expand All @@ -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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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:

Copy link
Member Author

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.


- 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.
Copy link
Member

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:

Suggested change
- 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.

Copy link
Member Author

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.

- 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).
Copy link
Member

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:

Suggested change
- 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.

Copy link
Member Author

@Josh-Cena Josh-Cena Jul 30, 2025

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.


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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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>.

Copy link
Member Author

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

Copy link
Member

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.

Copy link
Member Author

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.


The form control that a label is labeling is called the _labeled control_ of the label element. Multiple labels can be associated with the same form control:

```html
Expand All @@ -57,32 +97,11 @@ The form control that a label is labeling is called the _labeled control_ of the

Elements that can be associated with a `<label>` element include {{HTMLElement('button')}}, {{HTMLElement('input')}} (except for `type="hidden"`), {{HTMLElement('meter')}}, {{HTMLElement('output')}}, {{HTMLElement('progress')}}, {{HTMLElement('select')}} and {{HTMLElement('textarea')}}.

## 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.

## 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.

## Accessibility

### Interactive content

Don't place interactive elements such as {{HTMLElement("a", "anchors")}} or {{HTMLElement("button", "buttons")}} inside a `label`. Doing so makes it difficult for people to activate the form input associated with the `label`.
Don't place additional interactive elements such as {{HTMLElement("a", "anchors")}} or {{HTMLElement("button", "buttons")}} inside a `label` (the only interactive child should be the element being labeled, if you are using [implicit association](#associating_a_label_with_a_form_control)). Doing so makes it difficult for people to activate the form input associated with the `label`.

**Don't do this:**

Expand All @@ -96,15 +115,18 @@ Don't place interactive elements such as {{HTMLElement("a", "anchors")}} or {{HT
**Prefer this:**

```html example-good
<p>
<a href="terms-and-conditions.html">Read our Terms and Conditions</a>
</p>
<label for="tac">
<input id="tac" type="checkbox" name="terms-and-conditions" />
I agree to the Terms and Conditions
</label>
<p>
<a href="terms-and-conditions.html">Read our Terms and Conditions</a>
</p>
```

> [!NOTE]
> It is also 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.

### 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.
Copy link
Member

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.

Expand Down