# IDs of active elements must be unique

> Canonical HTML version: https://rocketvalidator.com/accessibility-validation/axe/4.11/duplicate-id-active
> Attribution: Rocket Validator (https://rocketvalidator.com)
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

The `id` attribute serves as a unique identifier for an element within an HTML document. When `id` values are duplicated on active, focusable elements (elements that can receive keyboard focus, like inputs, buttons, links, and elements with `tabindex`), it creates a fundamental problem: the browser and assistive technologies have no reliable way to distinguish one element from another. This is different from duplicate IDs on non-focusable elements — while still invalid HTML, duplicate IDs on focusable elements have a more direct and serious impact on accessibility.

## Why this matters

Screen readers rely on unique `id` values to build their internal model of the page. When a label references an `id` via the `for` attribute, or when `aria-labelledby` or `aria-describedby` points to an `id`, the assistive technology will typically only resolve the first element with that `id`. This means:

- **Form labels may point to the wrong control.** A `<label>` using `for` to reference a duplicated `id` will only be associated with the first matching element. The second form control becomes unlabeled for screen reader users.
- **ARIA relationships break.** Attributes like `aria-labelledby`, `aria-describedby`, and `aria-controls` depend on unique IDs to function correctly.
- **Table header associations fail.** When `<td>` elements use the `headers` attribute to reference `<th>` elements by `id`, duplicated IDs cause incorrect or missing header announcements.
- **Client-side scripts malfunction.** JavaScript methods like `document.getElementById()` return only the first matching element, so event handlers and dynamic behavior may not apply to the intended element.

Users who are blind or deafblind are most seriously affected, as they depend entirely on assistive technology to navigate and interact with focusable elements. The user impact of this issue is considered **serious**.

While WCAG 2.0's Success Criterion 4.1.1 (Parsing) originally required valid markup including unique IDs, this criterion was deprecated in WCAG 2.2 because modern browsers handle parsing errors more consistently. However, duplicate active IDs still cause real accessibility failures — particularly violations of **SC 1.3.1 (Info and Relationships)** and **SC 4.1.2 (Name, Role, Value)** — because they break the programmatic associations that assistive technology depends on.

## How to fix it

1. **Identify all focusable elements with duplicate `id` values.** You can use the axe accessibility checker, browser developer tools, or the [W3C HTML Validator](http://validator.w3.org) to find duplicates.
2. **Assign a unique `id` to each focusable element.** Append a distinguishing suffix, use a naming convention, or generate unique identifiers.
3. **Update all references** to the renamed IDs, including `<label for="">`, `aria-labelledby`, `aria-describedby`, `aria-controls`, `headers`, and any JavaScript that targets the element by `id`.

## Examples

### Incorrect: duplicate `id` on focusable elements

In this example, two input fields share the same `id` of `"email"`. The label only associates with the first input, leaving the second input unlabeled for screen reader users.

```html
<label for="email">Personal Email</label>
<input type="email" id="email" name="personal_email">

<label for="email">Work Email</label>
<input type="email" id="email" name="work_email">
```

### Correct: unique `id` on each focusable element

Each input has a distinct `id`, and each label correctly references its corresponding control.

```html
<label for="personal-email">Personal Email</label>
<input type="email" id="personal-email" name="personal_email">

<label for="work-email">Work Email</label>
<input type="email" id="work-email" name="work_email">
```

### Incorrect: duplicate `id` breaking ARIA relationships

Here, two buttons share the same `id`, so `aria-describedby` on the dialog can only resolve to the first button — the description association for the second context is lost.

```html
<button id="save-btn" aria-describedby="save-help">Save Draft</button>
<p id="save-help">Saves without publishing.</p>

<button id="save-btn" aria-describedby="publish-help">Save & Publish</button>
<p id="publish-help">Saves and makes content live.</p>
```

### Correct: unique `id` values with proper ARIA references

```html
<button id="save-draft-btn" aria-describedby="save-help">Save Draft</button>
<p id="save-help">Saves without publishing.</p>

<button id="save-publish-btn" aria-describedby="publish-help">Save & Publish</button>
<p id="publish-help">Saves and makes content live.</p>
```