# Form fields should not have multiple label elements.

> Canonical HTML version: https://rocketvalidator.com/accessibility-validation/accesslint/0.16/labels-and-names/multiple-labels
> Attribution: Rocket Validator (https://rocketvalidator.com)
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

When a form field has more than one `<label>` element associated with it, screen readers may read only one of the labels, read them in an unpredictable order, or ignore some of them entirely. The behavior varies across assistive technology and browser combinations, so there is no reliable way to ensure that all labels are announced correctly. This makes the form harder to understand for screen reader users, who depend on label announcements to know what information a field expects.

A `<label>` can be associated with a form field either by wrapping the field or by using a `for` attribute that matches the field's `id`. If two or more `<label>` elements reference the same field through either mechanism, the field has multiple labels.

This rule relates to WCAG success criterion 4.1.2 (Name, Role, Value) at Level A. That criterion requires that all user interface components have a name that can be programmatically determined. When multiple `<label>` elements compete for that role, the programmatically determined name becomes ambiguous, and the result depends on implementation details of each browser and screen reader pairing.

## How to fix it

The fix depends on why multiple labels exist.

If the labels contain separate pieces of information that both describe the field, combine them into a single `<label>` element. Use `<span>` elements inside the label if you need to style the pieces differently.

If one label is the primary name for the field and the other provides supplementary instructions (such as format hints or constraints), keep the primary `<label>` and move the supplementary text into a separate element referenced by `aria-describedby`. Screen readers will announce the label first, then the description, giving users all the information without the ambiguity of duplicate labels.

If the extra label was added by accident or through a templating error, remove it.

## Examples

### Incorrect: two labels pointing to the same field

```html
<label for="email">Email</label>
<label for="email">Required</label>
<input type="text" id="email">
```

Both `<label>` elements have `for="email"`, so the input has two labels. A screen reader might announce only "Email" or only "Required", depending on the implementation.

### Correct: single label with all necessary text

```html
<label for="email">Email (required)</label>
<input type="text" id="email">
```

All information is in one `<label>`, so the accessible name is unambiguous.

### Correct: single label with supplementary text via `aria-describedby`

```html
<label for="email">Email</label>
<input type="text" id="email" aria-describedby="email-hint">
<span id="email-hint">Required. Use the format name@example.com.</span>
```

The field has one `<label>` for its accessible name and a separate element for the supplementary hint. Screen readers announce the label as the field name and the `aria-describedby` content as the description.

### Correct: styled pieces inside a single label

```html
<label for="email">
  <span class="label-text">Email</span>
  <span class="label-required">*</span>
</label>
<input type="text" id="email">
```

Even though the text is split across `<span>` elements for styling purposes, there is only one `<label>` wrapping them, so the accessible name is clear.