Skip to main content
Beta: Front-End Checklist is currently in beta. Some issues are still being fixed. Thanks for your patience.

Use unique IDs for active elements

All focusable or active elements must have a unique ID attribute.

Utilities
Quick take
Typical fix time 10 min
  • Ensure all focusable elements (links, buttons, inputs) have unique id values
  • Avoid duplicate IDs that can break keyboard navigation and focus management
  • Prevent screen reader confusion when navigating interactive controls
Why it matters: Duplicate IDs on active elements can cause browsers and assistive technologies to skip items, misdirect focus, or fail to trigger the correct action.

Rule Details

Every interactive element on a page must have a unique ID to ensure that browsers and assistive technologies can uniquely identify and interact with them.

Code Example

<!-- ✅ Good: Unique IDs for each input -->
<label for="first-name">First Name</label>
<input id="first-name" type="text">
 
<label for="last-name">Last Name</label>
<input id="last-name" type="text">
 
<!-- ❌ Bad: Duplicate IDs on active elements -->
<button id="submit-btn">Save</button>
<button id="submit-btn">Cancel</button> <!-- Error: ID must be unique -->

Why It Matters

  • Focus Management: Browsers use IDs to track which element currently has focus. Duplicate IDs can lead to focus being lost or moved to the wrong element.
  • Keyboard Navigation: Users navigating by keyboard may find that some interactive elements are unreachable if they share an ID with another element.
  • Assistive Technology: Screen readers often use IDs to build a map of the page's interactive controls. Duplicate IDs corrupt this map.

Best Practices

Automate Checks: Use linters or accessibility auditors to catch duplicate IDs during development. ✅ Use Prefixes: In component-based frameworks, use unique prefixes or generated IDs to avoid collisions between multiple instances of the same component. ✅ Semantic Labels: Always ensure for attributes on labels match the unique id of their corresponding input.

Tools & Validation

Exceptions

  • Evaluate the rendered experience before treating a static-code smell as a blocker; interaction timing, browser behavior, and assistive technology output often determine severity.
  • Not every secondary accessibility issue deserves equal weight; prioritize the issue that most directly blocks perception, operation, or understanding.
  • Avoid adding redundant markup or ARIA solely to satisfy a rule when a simpler semantic implementation would eliminate the issue entirely.

Standards

  • Align the implementation with W3C WAI: WCAG Overview and verify the rendered experience, not only the source code.
  • Align the implementation with MDN: Accessibility and verify the rendered experience, not only the source code.

Verification

Automated Checks

  • Inspect the browser accessibility tree or accessibility pane for the relevant element, role, or accessible name.
  • Run an automated accessibility checker such as axe or Lighthouse where applicable.

Manual Checks

  • Test the affected UI with keyboard-only navigation and confirm the rule holds in the rendered experience.
  • Re-test one representative user flow with a screen reader if this rule affects a key interaction.

Use with AI

Copy these prompts to use with your AI assistant, or install the MCP server to use directly from Claude, Cursor, or Windsurf.

Check

Verify implementation

Search for duplicate id attributes on focusable or active HTML elements.

Fix

Auto-fix issues

Assign a unique id to each active element to ensure correct focus handling and accessibility.

Explain

Learn more

Explain how unique IDs on active elements prevent navigation errors for keyboard and screen reader users.

Review

Code review

Review the rendered markup and interactive states that affect Use unique IDs for active elements. Flag exact elements, roles, labels, focus behavior, or keyboard interactions that violate the rule, and note how to verify the fix with browser accessibility tooling or assistive tech.

Sources

References used to support the guidance in this rule.

Further Reading

Tools and supplementary material for exploring the topic in more depth.

axe DevTools
deque.comTool

Rules that often go hand-in-hand with this one.

Ensure headings contain text

All heading elements (h1-h6) must have visible, descriptive content.

Accessibility
Place list items within list containers

List item elements (li) must always be direct children of a list container (ul, ol, or menu) to maintain valid HTML structure and correct screen reader announcements.

Accessibility
Ensure tables have unique accessible names

Checks that data tables have unique accessible names

Accessibility
Set the page lang attribute

The <html> element must have a lang attribute with a valid BCP 47 language code so screen readers, translation tools, and search engines know the primary language of the page.

HTML

Was this rule helpful?

Your feedback helps improve rule quality. This stays internal for now.

Loading feedback...
0 / 385