Overview
Interactive elements (buttons, inputs, landmarks) must have an accessible name so assistive technology can announce what they do.
ARIA labels give assistive technology an “accessible name”—the text a screen reader announces for a control. Icon-only buttons (a bare hamburger, a trash can, a magnifying glass) are the classic offender: visually obvious, but announced as just “button.” The first rule of ARIA is to use native HTML where possible, but when you build custom controls or icon buttons, a correct aria-label (WCAG 4.1.2) is what makes them usable.
The Problem
This pattern is inaccessible — avoid it.
The Fix
Use this accessible pattern instead.
Step-by-step
Every icon-only button must have aria-label or aria-labelledby.
Dialogs/modals need aria-labelledby pointing to the visible heading.
When there are multiple <nav> landmarks, give each an aria-label.
Add aria-hidden="true" to decorative SVGs/icons so screen readers skip them.
Common Mistakes
Icon-only buttons or links with no aria-label.
Decorative SVGs left without aria-hidden="true", cluttering the screen reader.
Multiple <nav> or <section> landmarks with no distinguishing label.
Overriding a visible label with a different aria-label, which confuses voice-control users.
How to Test for It
Tab to each icon button in a screen reader and confirm it announces a clear name.
Inspect the accessibility tree in DevTools—every control should have a non-empty name.
Run an automated scan for controls missing an accessible name.
Framework Notes
How to apply this fix in your stack.