ARIA labels without the guesswork

I see aria-label added to components as a quick accessibility fix. The intent is good. The result depends on whether the element needed a name in the first place.

An accessible name is the short label that assistive technology uses to identify an element. A screen reader may announce a button as “Save, button.” In that case, “Save” is the accessible name.

HTML can provide that name without any ARIA:

<button type="button">Save</button>

The text inside the button already does the job. Adding aria-label="Save" repeats information and gives you another string to maintain.

Start with HTML

The first question I ask is whether HTML already has the right element or attribute. A button gives you button semantics and keyboard behavior. A label connects text to a form control. A link tells the browser that the user can go somewhere.

<label for="email">Email address</label>
<input id="email" name="email" type="email">

The visible label helps sighted users, expands the clickable area, and provides the input’s accessible name. The W3C guidance on accessible names recommends visible text and native HTML for the same reasons.

ARIA can describe semantics, but it does not add browser behavior. A div with role="button" still needs focus handling and keyboard support. A native button brings those pieces with it.

Give aria-label a specific job

aria-label earns its place when an interactive element has no useful visible text. Icon-only controls are the common example:

<button type="button" aria-label="Close">
  <span aria-hidden="true">×</span>
</button>

The symbol gives sighted users a visual cue. The accessible name tells a screen reader user what the button does. aria-hidden="true" keeps the decorative symbol out of the accessibility tree.

Landmarks can also benefit from a name when a page has more than one of the same type:

<nav aria-label="Primary">
  ...
</nav>

<nav aria-label="Footer">
  ...
</nav>

A screen reader user can distinguish the two navigation regions without any change to the visible interface.

aria-label can replace useful text

Browsers give aria-label priority when they calculate an accessible name. That means it can replace the text inside a button or link.

<button type="button" aria-label="Delete item">
  Remove
</button>

A sighted user sees “Remove.” A screen reader user hears “Delete item.” Someone using voice control may say “Click Remove” and get no match.

The WCAG guidance for Label in Name says the accessible name should contain the visible label. The easiest fix in this example is to let the button text name itself:

<button type="button">Remove</button>

If the control needs more context, keep the visible word in the accessible name:

<button type="button" aria-label="Remove Jordan from the team">
  Remove
</button>

Now “Remove” stays visible and remains part of the name used by assistive technology.

A placeholder is not a label

Placeholder text disappears once someone starts typing. It can also create contrast and memory problems. I give form controls a persistent label and use a description for supporting instructions.

<label for="password">Password</label>
<input
  id="password"
  name="password"
  type="password"
  aria-describedby="password-help"
>
<p id="password-help">Use at least 12 characters.</p>

The label names the input. aria-describedby connects the extra instruction without stuffing it into the name.

Test the name a user gets

I check the accessibility tree in browser developer tools to see the computed name and role. I also tab through the interface and try the control without a mouse. Automated checks can find a missing name, but they cannot tell me whether “Action button” makes sense in context.

For a custom interaction, I compare the implementation with the relevant pattern in the ARIA Authoring Practices Guide. The guide calls out an important risk: incorrect ARIA can misrepresent the interface for someone who cannot see it.

My working checklist is short:

• Use the native element.
• Prefer a visible label.
• Add aria-label when no useful text can provide the name.
• Keep the accessible name aligned with any visible text.
• Test the computed name, role, and keyboard behavior.

aria-label is useful when I give it one clear job. Most of the time, good HTML has already handled the first step.