Provide accessible names for all interactive elements
Checks that interactive elements have accessible names for clear navigation.
- Buttons, links, and other controls must have a discernable name
- Names should be concise and describe the action or destination
- Avoid generic names like 'Click Here' or 'More'
Rule Details
Every interactive element on a page must communicate its purpose to assistive technologies. WAI-ARIA 1.2 (opens in new tab) treats accessible naming as foundational for buttons, links, and widgets, which is why this rule often overlaps with ARIA command names.
Code Example
<!-- ✅ Correct: Descriptive label for icon button -->
<button aria-label="Download PDF report">
<i class="icon-download"></i>
</button>
<!-- ✅ Correct: Descriptive link text -->
<a href="/pricing">View our subscription plans</a>
<!-- ❌ Incorrect: Non-descriptive label (Too generic) -->
<a href="/article/123">Read more</a>
<!-- ❌ Incorrect: No label (Icon-only without description) -->
<button>
<span class="glyph-print"></span>
</button>Why It Matters
- Efficiency: Helps users quickly scan and find the right control when using a screen reader's "elements list."
- Searchability: Clear labels are vital for users who navigate via voice control, as they need to speak the name of the control to activate it.
- Clarity: Removes ambiguity about what will happen when a control is activated, reducing user anxiety and errors.
- Consistency: Ensures that the experience for screen reader users matches the visual intent of the design.
Exceptions
- Prefer native HTML semantics over ARIA when both are possible; some apparent ARIA failures disappear when the underlying element is corrected.
- A missing ARIA attribute is not automatically the strongest finding if the control is already semantically broken, unnamed, or keyboard-inaccessible.
- Do not add ARIA only to satisfy the rule if the feature should instead be implemented with a native element or a simpler interaction pattern.
Standards
- Align the implementation with WAI-ARIA 1.2 and verify the rendered experience, not only the source code.
- Align the implementation with MDN: ARIA 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
Audit all interactive elements (buttons, links, widgets) for missing or unhelpful accessible names.
Fix
Auto-fix issues
Add descriptive text content or `aria-label` attributes to all interactive elements.
Explain
Learn more
Explain how clear labels on interactive elements improve accessibility and general usability.
Review
Code review
Review the rendered markup and interactive states that affect Provide accessible names for all interactive 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.