ARIA Labels in HTML: aria-label, aria-labelledby & Accessibility (Beginner Guide)

An ARIA label is text that is read by assistive technology, even if it is not visible on the screen.

A screen reader needs an accessible name for interactive elements like buttons, links, and form fields. If the visible text is unclear (or missing), ARIA labels help provide that missing meaning.

For example, this button is visually understandable, but not descriptive for a screen reader:

<button>X</button>

“X” could mean close, delete, remove, cancel, or dismiss. A screen reader may announce this as “button, X”, which is vague.

Now compare it with an ARIA label:

<button aria-label="Close dialog">X</button>

This gives the element a meaningful accessible name. A screen reader can announce something like:

“Close dialog, button”

That is the core idea behind ARIA labels: turn vague UI into clear meaning.

Before you add ARIA, always ask:

“Can semantic HTML solve this first?”

Semantic HTML is automatically accessible most of the time. For example:

• A real <button> is already announced as a button.
• A real <label> connected to an <input> is already announced correctly.
• A real <nav> is already recognized as navigation.

ARIA should not replace semantic HTML. It should support it when needed.

A good accessibility mindset is:

Use HTML first. Use ARIA only when HTML can’t describe the UI clearly.

These three attributes are often confused, so let’s make them crystal clear.

1) aria-label (you write the label directly)

Use aria-label when you need to provide a name, and there is no visible text that can be used.

Example (icon-only button):

<button aria-label="Open navigation menu">☰</button>

This is simple, direct, and very common.

2) aria-labelledby (the label comes from existing content)

Use aria-labelledby when the label already exists somewhere on the page (as real text), and you want to reuse it.

Example:

<h2 id="account-title">Account settings</h2>
<button aria-labelledby="account-title">⚙️</button>

This tells assistive technologies: “Use the text from #account-title as the button name.”

aria-labelledby is often preferred because it reuses visible text and stays consistent if the content changes.

3) aria-describedby (extra help text, not the main label)

Use aria-describedby when an element already has a label, but needs additional explanation.

Example:

<label for="password">Password</label>
<input id="password" type="password" aria-describedby="password-help">

<p id="password-help">
  Must be at least 8 characters and include a number.
</p>

The label is still “Password”, but the help text is also announced.

Icon-only buttons (delete, close, settings)

Icons are great for UI, but screen readers need actual meaning.

Bad (no accessible name):

<button>🗑️</button>

Good (clear accessible name):

<button aria-label="Delete item">🗑️</button>

Decorative icons inside buttons (alt text vs aria-label)

If an image is decorative and the button already has a label, the image should not be read.

Example:

<button aria-label="Settings"> <img src="settings-icon.svg" alt=""> </button>

Notice: alt="" means “don’t announce this image.” The button name comes from aria-label.

“Read more” links (link lists problem)

Screen reader users often navigate by listing links. If you have ten links that all say “Read more”, the list becomes useless.

Not great:

<a href="/post-1">Read more</a> <a href="/post-2">Read more</a>

Better (same visible text, better accessible meaning):

This improves accessibility and clarity without changing design.

Search inputs without visible labels (avoid if possible)

Best practice is to use a real <label>.

Recommended approach (label exists for accessibility):

<label for="search">Search</label> <input id="search" type="search">

If your design hides the label visually, you still keep it in HTML (best approach for accessibility and SEO clarity).

If you truly cannot use a label, then:

<input type="search" aria-label="Search" placeholder="Search...">

To implement ARIA labels effectively, follow these best practices:

• Use the aria-label attribute: Provide a concise label directly to an element using the aria-label attribute when necessary.

  <button aria-label="Mute audio">🔊</button>

• Leverage ARIA roles and properties: Combine ARIA labels with appropriate roles and properties to provide comprehensive accessibility information.

  <div role="progressbar" aria-valuenow="70" aria-valuemin="0" aria-valuemax="100" aria-label="Page loading progress"></div>

• Keep labels concise and descriptive: Create meaningful and descriptive labels that accurately represent the purpose or functionality of the element.

  <input type="checkbox" aria-label="Accept terms and conditions">

• Test with assistive technologies: Verify the implementation using screen readers or other assistive technologies to ensure proper announcement of ARIA labels.

ARIA roles help describe what something is, especially in custom components like tabs, accordions, modals, and sliders.

Example: tab interface (simplified structure):

<div role="tablist" aria-label="Product information">
  <button role="tab" aria-selected="true" id="tab-description">
    Description
  </button>

  <button role="tab" aria-selected="false" id="tab-reviews">
    Reviews
  </button>
</div>

<div role="tabpanel" aria-labelledby="tab-description">
  Description content...
</div>

<div role="tabpanel" aria-labelledby="tab-reviews" hidden>
  Reviews content...
</div>

This combination tells assistive technologies:

• these buttons behave like tabs
• one is selected
• each tab controls a panel

This is how ARIA “fills the gap” for custom interfaces.

Mistake 1: Adding ARIA to already-semantic elements

This is redundant and sometimes confusing:

<button role="button">Save</button>

A <button> is already a button. Don’t add extra roles unless necessary.

Mistake 2: Wrong role for the wrong purpose

If it navigates, it should be a link. If it triggers an action, it should be a button.

Bad:

<a href="/logout" role="button">Logout</a>

Better:

<a href="/logout">Logout</a>

Or, if logout is an action handled with JavaScript:

<button type="button">Logout</button>

Mistake 3: Writing long ARIA labels

ARIA labels should be short and actionable.

Good:

• “Close dialog”
• “Open menu”
• “Delete item”
• “Search site”

Bad:

• “Click this button to close the dialog window currently open on the screen”

• Use semantic HTML first
• Use aria-label for icon-only UI
• Prefer aria-labelledby when the label already exists as visible text
• Use aria-describedby for extra help text
• Keep labels short and meaningful
• Don’t add ARIA roles to native semantic elements unless truly needed
• Test your UI using browser accessibility tools or a screen reader

What is an ARIA label?

An ARIA label is an accessibility attribute that provides a readable name for an element so screen readers can describe it correctly.

When should I use aria-label?

Use aria-label when an element (like an icon-only button) has no visible text label but still needs a clear accessible name.

What is the difference between aria-label and aria-labelledby?

aria-label provides the label directly as a string.
aria-labelledby references existing text on the page (usually preferred when available).

Does ARIA improve SEO?

ARIA is primarily for accessibility, not ranking. However, accessibility improvements often align with better structure, usability, and clarity — which can indirectly support overall site quality.

ARIA labels are one of the simplest ways to improve HTML accessibility for screen readers — especially in modern UI designs that rely heavily on icons and custom components.

The key is to treat ARIA as a helper, not a replacement for semantic HTML. When used correctly, aria-label, aria-labelledby, and aria-describedby make your website more inclusive and easier to understand for everyone.

In the next lesson, we’ll cover SEO for HTML, where you’ll learn how to structure your content so search engines can understand and rank your pages effectively.