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:

• Bad: aria-label=”Click here to open menu”

• Good: aria-label=”Open menu”

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

1. Icon-Only Button

<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>

4. Using Standard HTML Form Labels

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

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.