The aria-label attribute assigns an accessible name to an element when visible text or other naming mechanisms aren’t available or adequate. It’s particularly useful when elements like icon-only buttons or custom widgets lack meaningful text.
When to use it:
-
Icon-only buttons or controls without text labels.
-
Custom UI components where native semantics are insufficient.
-
When visual clutter is best avoided but accessibility needs a descriptive name.
Common Mistakes & Misuses
1. Redundant Labeling on Textful Elements
Adding aria-label to elements that already contain visible textual labels is unnecessary and can even override the displayed text—potentially confusing assistive technology users. For example:
<!-- Bad -->
<button aria-label="Submit">Submit</button>
Better:
<!-- Good -->
<button>Submit</button>
2. Using aria-label Where aria-labelledby Is Better
When there’s existing visible text elsewhere that can serve as a label, aria-labelledby should be used:
<!-- Bad -->
<section aria-label="Related Articles">
<h2>Related</h2>
…
</section>
<!-- Good -->
<section aria-labelledby="related-label">
<h2 id="related-label">Related</h2>
…
</section>
3. Applying aria-label on Unsupported Elements
Some elements (like <p>, <span>, or non-interactive roles) should not have aria-label. Doing so may be ignored or trigger validation issues:
<!-- Bad -->
<p aria-label="Shipping instructions:"></p>
<!-- Good -->
<p>Shipping instructions:</p>
4. Overused or Incorrect ARIA Instead of Native HTML
Using ARIA to compensate for poor HTML structure is discouraged. Example:
<!-- Bad -->
<span role="button" aria-label="Submit">Submit</span>
<!-- Good -->
<button>Submit</button>
5. Overly Descriptive, Redundant, or Misleading Labels
Avoid words like “click,” “press,” or “button” in the aria-label, and ensure labels remain succinct:
Also, make sure referenced IDs in aria-labelledby or related attributes are valid—broken references break usability.
6. Ignoring Keyboard Behavior on Custom Elements
Adding ARIA to non-semantic elements (like <div role=”button”>) doesn’t automatically make them keyboard-accessible—developers must add keyboard handling manually:
<div role="button" tabindex="0" aria-label="Close dialog" onclick="close()"></div>
This still needs onkeydown to function properly.
7. Accessible Name ≠ Visible Label
Because aria-label overrides visible text, mismatches can cause confusion—especially in voice-controlled interfaces where “Click More” fails if aria-label=”More about fishes” is used:
Good Practices & Correct Usage
<button aria-label="Close">
<svg aria-hidden="true" focusable="false">…</svg>
</button>
This ensures screen readers announce “Close, button.”
2. Custom Control Without Native Label
<button aria-label="Close menu">
<svg role="img" aria-hidden="true">…</svg>
</button>
Useful when combining a clean UI with accessibility needs.
3. Using aria-labelledby for Sections
<section aria-labelledby="related-label">
<h2 id="related-label">Related</h2>
…
</section>
Prefer real <label> elements over aria-label for inputs:
<label for="name">Your name:</label>
<input type="text" id="name">
This approach supports focus, accessibility, and user interaction.
Quick Reference Table
|
Scenario
|
Use Case
|
Example
|
|
Icon-only button
|
No visible text, needs an accessible name
|
<button aria-label=”Close”><svg…/></button>
|
|
Already labeled element
|
Button has text, no aria-label needed
|
<button>Submit</button>
|
|
Referencing visible text
|
Use aria-labelledby instead
|
<section aria-labelledby=”id”>…
|
|
Unsupported element
|
Don’t use aria-label on text-only elements
|
<p aria-label=”…”>…</p> – remove it
|
|
Custom control
|
Use ARIA wisely, with all behaviors
|
<div role=”button” tabindex=”0″ …> with keyboard events
|
Final Thoughts: “No ARIA” Often Beats Bad ARIA
ARIA is a powerful but potentially dangerous tool—misuse can make your site less accessible. Prioritize native HTML, use ARIA only when necessary, and always test across screen readers and assistive technologies.
