Skip to main content :::
:::

How to Implement Accessible Names in HTML

Accessible names help assistive technologies identify the purpose of buttons, links, and form fields. This guide explains how to use native HTML and visible text first, then add aria-label or aria-labelledby when needed.


Summary

  • An accessible name answers what a control is called or what it does.
  • In most cases, visible text, labels, alt text, and semantic HTML are the most stable source.
  • aria-label and aria-labelledby are supporting tools, not a way to hide unclear visible text or broken structure.

Accessible names solve a naming problem

An accessible name is the name a browser exposes to assistive technologies. When someone reaches a button, link, form field, or custom control, a screen reader commonly announces both the role and the name, such as “Search, button” or “Email, text field.”

It is not marketing copy, and it should not repeat everything visible on the page. Its job is simple: help the user understand what the control is, what it does, and whether it is worth acting on.

Start with native HTML and visible text

The most stable accessible names usually come from native HTML, not ARIA. Visible button text, clear link text, form labels, and alt text for meaningful images are easier for teams to understand and maintain than hidden fallback text in attributes.

When visible text is clear, assistive technologies, voice control tools, translation tools, and sighted users are more likely to receive consistent information.

  • Buttons: prefer clear button text, such as “Save draft,” instead of an icon alone.
  • Links: avoid “more” or “click here” when the link text can describe the destination.
  • Form fields: associate fields with labels; placeholder text is not a replacement for a label.
  • Images: use alt text for meaningful images and avoid announcing purely decorative images.
  • Groups: use fieldset and legend when a group of fields needs shared context.

When ARIA is useful

ARIA is useful when native HTML cannot express the needed relationship, but it should not be the first choice. If visible text already exists, aria-labelledby usually keeps the accessible name connected to that text. Use aria-label mainly when no suitable visible text is available.

Common cases include icon-only buttons, complex widgets named by a nearby heading, or repeated controls that look similar but perform different actions.

Common mistakes

Accessible name issues are not always about missing names. Often the name exists, but it does not match the real purpose. Automated tools can find some gaps, but people still need to confirm whether the name makes sense in context.

  • An icon-only button has no name, so users only hear “button.”
  • Several links on the same page are all named “More” even though they go to different places.
  • Placeholder text is used as the only form label, then disappears after input.
  • aria-label conflicts with visible text, giving different users different information.
  • Supporting text is placed in aria-describedby and mistaken for the control name.
  • The name does not update when state changes, such as expand, collapse, add, or remove.

How to test accessible names

Browser developer tools usually let you inspect the accessibility tree and review the current element’s role, name, and description. This is a useful starting point for understanding what assistive technologies receive.

DevCheck can help surface missing accessible names, ARIA mistakes, and some form-label issues. Still, machine checks only point to suspicious places; people need to decide whether the name fits the task and is clear enough.

  • Move through controls with the keyboard and confirm the focus order matches the page.
  • Inspect name, role, and description in the accessibility tree.
  • Use automated checks to find missing names, empty names, and ARIA relationship errors.
  • Spot-check with a screen reader or voice control tool to confirm the name works in real use.

Make it part of the workflow

Accessible names are not only an engineering task. Designers can document icon-button purpose, content teams can write clearer link text, QA can check focus and names in core flows, and product owners can avoid relying only on icons or visual placement for important actions.

This review does not need to wait for a formal audit. The earlier a name is made clear, the lower the repair cost tends to be, and the easier it is for the team to discuss one concrete issue.

Related pages