Blog October 22, 2026 · 14 min read

ARIA Labels Best Practices: When, Why and How to Use Them

Use an ARIA label only when no visible text or native HTML element can name the control. When you do use one, keep it short, make it start with the visible text, describe the action instead of the shape, and test it with a screen reader. Most label bugs we see come from skipping one of those four habits.

This guide covers how aria-label behaves, how it differs from a real <label>, how to label form fields and announce errors, and where aria-live fits. It also covers what automated scanners can and cannot tell you about labels.

AccessWiser

Find and Fix Accessibility Issues

AccessWiser scans websites against WCAG 2.2 AA, linking code-level findings to affected elements and offering guidance for permanent fixes.

Explore AccessWiser

TL;DR

Native HTML comes first: a <label> for form fields and a <button> with text for actions. Reach for aria-label only when there is no visible text to point to.
Good accessible names are short, usually one to three words, describe function rather than form, and leave the role out (“Close”, not “Close button”).
If a control has visible text, the accessible name must contain it, per WCAG 2.5.3 Label in Name.
Live regions announce changes such as form errors, but only if the region exists before its content changes.
A clean scan does not prove a label makes sense. Pair automated checks with a screen reader pass.

What an ARIA label actually does
Prefer native HTML first
When aria-label is the right tool
Seven rules for writing good ARIA labels
aria-label vs label: which one for form fields?
Accessible form validation and aria-live regions
ARIA roles and attributes: use as little as you need
Common mistakes we see again and again
What automated checks can and cannot tell you about labels
Why this matters beyond the code
Our perspective: fix the HTML, not the symptom
Catch label problems before your users do
FAQ
Sources

What an ARIA label actually does

Every interactive element needs an accessible name. That is the string a screen reader announces and the text voice-control software matches when someone says “click Search.” The W3C describes it as a short string, typically one to three words, that tells assistive technology users what an element is for.

The name can come from several places: the text inside a button, a <label> tied to an input, an alt attribute on an image, or an ARIA attribute. aria-label is the blunt tool in that list. According to the W3C technique for using aria-label, it supplies a text label that assistive technology reads for an object such as a button. The value is never drawn on screen.

That invisibility is the source of both its usefulness and its risk. Sighted users never see the string, so nobody on the design or content team notices when it drifts out of date.

Prefer native HTML first

The first rule of ARIA is simple: if a native element already has the meaning and behavior you need, use it. The W3C guidance treats aria-label as a secondary technique and tells authors to prioritize native elements, such as <label> for fields and <button> with text content.

There are practical reasons beyond the rule:

Maintenance. Visible text is edited by the people who edit the page. A hidden string is not.
Translation. Visible text flows through your translation process. Attribute values are often missed.
Consistency. What sighted users read and what assistive technology users hear stay in step.

W3C’s own guidance says that using visible text for names simplifies maintenance and prevents bugs, because markup-only names are easily overlooked when designers update the interface.

Here is the same search button, written two ways:

<!-- Fragile: name hidden in an attribute -->
<div role="button" tabindex="0" aria-label="Search"></div>

<!-- Robust: native element, visible text -->
<button type="submit">Search</button>

The second version brings keyboard support, focus handling and a name for free. If you reach for aria-label and find yourself rebuilding a button, stop and use the real element.

When aria-label is the right tool

There are honest cases where no visible text exists and a name is still required:

Icon-only buttons, such as a magnifying glass, a close X or a cart icon.
Landmark regions when a page has more than one of the same kind, for example two <nav> elements labeled “Main” and “Footer”.
Custom widgets where the design deliberately shows no text, such as a carousel control or a slider handle.
Search fields that rely on a nearby button for context instead of a visible caption.

For icon-only controls, we cover the patterns in more depth in our guide to icon button accessibility for developers.

<button type="button" aria-label="Close">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

Note the aria-hidden on the icon. The button gets its name from the attribute, and the decorative graphic stays out of the way.

Seven rules for writing good ARIA labels

1. Name the function, not the form

People using a screen reader need to know what happens when they activate something. A magnifying glass is a shape. “Search” is a function. The same goes for “X” versus “Close”, or “Hamburger” versus “Menu”.

2. Leave the role out

Screen readers announce the role automatically. Write “Close” and users hear “Close, button.” Write “Close button” and they hear the word twice. The W3C guidance on names recommends avoiding the role in the name for exactly this reason.

3. Keep it short

One to three words is the target. A long label slows down someone who is moving through a page control by control. If you need to add detail, such as “Opens in a new window” or “Required, 10 digits”, that belongs in a description, not the name. Use aria-describedby and point it at visible helper text.

4. Start with the visible text

This is the rule that catches the most real-world bugs. WCAG 2.5.3, Label in Name, exists because people using speech input rely on the visible label to activate a control. If your button reads “Send” and its aria-label is “Submit form”, a voice user saying “click Send” gets nothing.

The fix is to make the accessible name contain the visible text, in the same order. A name like “Send message” for a button reading “Send” works. A name that never mentions “Send” does not.

5. Make each label unique where it matters

Five links all named “Read more” give a screen reader user a list of identical options. Either extend the visible text or add context in the name, such as “Read more about spring menu changes”. Keep the visible words at the start so rule 4 still holds.

6. Do not put aria-label on elements that cannot use it

Naming is not reliable on every element. A plain <div> or <span> with no role is not a good place for it, and support is inconsistent. Give the element a proper role or, better, use a native element.

7. Remember it overrides content

When an element has aria-label, screen readers present the attribute value instead of the element’s own content. Put one on a complex component, such as a card with a heading, price and button, and you can hide everything inside it from some users. Always check the calculated accessible name in your browser’s accessibility inspector and confirm it matches what you expect.

aria-label vs label: which one for form fields?

For form fields, use a <label>. Always. It is the better answer on nearly every count:

	`<label for>`	`aria-label`
Visible on screen	Yes	No
Larger click target (tapping the label focuses the field)	Yes	No
Picked up by translation tools	Usually	Often missed
Matches what voice-control users say	By design	Only if you match it by hand
Best for	Almost every text field, checkbox, radio, select	Fields with no room for a caption, such as a compact search box

A correctly labeled field looks like this:

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

There is also aria-labelledby, which points at the id of existing visible text. It is the better ARIA option when a name is already on screen but sits outside a <label>, for instance a heading that names a dialog or a section. It keeps one source of truth, so the visible text and the name cannot disagree.

Placeholder text is not a label. It disappears when someone types, it often fails contrast, and it is not a dependable name across tools. Keep a real label visible above or beside the field.

For a full walkthrough of the markup patterns behind this, including where scanners fall short, read our piece on form accessibility for developers.

Accessible form validation and aria-live regions

Labels name a field. Validation tells people what went wrong. Both have to work without sight.

A practical pattern for errors:

Put the error message in visible text next to the field, and say what to do: “Enter a date as MM/DD/YYYY”, not just “Invalid”.
Connect it to the input with aria-describedby, so the message is read with the field.
Mark the field with aria-invalid="true" once it fails.
On submit, move focus to the first error or to a summary at the top that links to each failing field.
Do not rely on color alone, and do not clear the user’s input.

ZIP code

Enter a 5-digit ZIP code.

Where aria-live fits

Some messages appear without the user moving focus: “Item added to cart”, “3 results found”, or an inline error that shows up after a field loses focus. A live region lets a screen reader announce those changes. MDN explains that the aria-live attribute sets the priority with which updates are handled, using the values off, polite or assertive.

A few working rules:

Default to polite. It waits until the user pauses. Save assertive for urgent problems, because it interrupts whatever is being read.
Create the region first. MDN advises starting with an empty live region and updating it later. If you add the region and its text in the same moment, many screen readers will say nothing.
Keep messages short and meaningful. Announce “Cart updated, 3 items”, not a whole table.
Do not wrap a whole page section in a live region. Constant chatter makes a page unusable.

For a status message that is a simple notice, role="status" gives you polite behavior built in. For a blocking error, role="alert" is assertive. Browser and screen reader combinations vary, which is one more reason to test.

ARIA roles and attributes: use as little as you need

Roles, states and properties each do a different job. A role says what something is (role="dialog"), a state says its current condition (aria-expanded), and a property describes a stable relationship (aria-labelledby). Adding them does not add behavior. A role="button" on a <div> announces a button but does not respond to Enter or Space unless you write that code.

More ARIA is not more accessible. Wrong ARIA can be worse than none, because it tells assistive technology something false. If you build tabs, comboboxes or menus, follow the published authoring patterns closely and test them. We have written up accessible tabs and combobox testing across JAWS, NVDA and VoiceOver for that reason.

Common mistakes we see again and again

A label that repeats the visible text with extra words. “Click here to submit your order form now” on a button reading “Order”.
Naming a <div> and hoping. Without a role or a native element, nothing reliable happens.
Labels in English on a translated page. The visible text is Spanish and the attribute is not.
Duplicate names for different actions, such as several “Edit” buttons in a table with no row context.
aria-label plus a <label> that disagree. The attribute wins, and voice users get stranded.
Hidden or decorative controls given labels, which adds noise.

What automated checks can and cannot tell you about labels

Automated tools are good at one kind of label problem: absence. They can find a button with no name, an input with no label, or an aria-label on an element that cannot take one. They are weak at judgment. A scanner can see that a name exists. It cannot know whether “Item” is a useful name for a delete button.

The ADA.gov guidance makes the same point: automated tools can detect many barriers but should be used carefully, and a clean report does not guarantee accessibility. The guidance also notes that checks like these work best alongside manual review.

The same caution applies to any automated audit of your site. Treat scan output as a to-do list for humans, not a verdict.

A quick manual pass for labels:

Tab through the page. Does every stop announce a clear name and role?
Open a screen reader’s list of links, buttons and form fields. Do the names make sense out of context?
Try speech input: say the visible text of each control. Does it activate?
Trigger each error and status message. Is it announced once, at the right time?

Our two-pass method is laid out in screen reader testing developers can run, and the keyboard half is in seven steps to test and fix keyboard accessibility.

Why this matters beyond the code

Labels are not a niche concern. Missing form labels and unnamed controls are among the barriers that stop people from checking out, booking a table or sending an inquiry. The ADA.gov web guidance lists barriers such as poor color contrast and missing text alternatives as common problems for people with disabilities.

One US note on standards. For state and local governments, the Department of Justice has named WCAG 2.1 Level AA as the technical standard under its Title II web rule. Private businesses do not have a single published technical rule for websites under Title I or III of the ADA, but WCAG AA is the benchmark most often used when sites are evaluated. Label in Name (2.5.3) and name, role, value (4.1.2) are part of that benchmark. If you have received a demand letter or are unsure of your exposure, speak to an attorney who handles ADA matters.

Our perspective: fix the HTML, not the symptom

We built AccessWiser around one belief: a label problem is a code problem, and it should be fixed in the code. When our scans flag an unnamed button or a field with no label, the finding names the element and the WCAG criterion it affects, and the guidance tells you how to correct it in your own markup. That way the fix stays when the page is redeployed.

Our perspective: fix the HTML, not the symptom — overview diagram

We are also deliberate about what automation can claim. A scanner can catch a missing name. It cannot tell you whether “Submit form” on a button that says “Send” will frustrate someone using voice control. So we recommend scans for the repeatable, high-volume checks, scheduled re-checks to catch regressions after a release, and a human screen reader pass for meaning. Dated records of each scan and fix then give you documented evidence of the work you have done.

It is easy to treat aria-label as a shortcut. We would rather you treat it as a signal: when you need one, ask whether the visible interface could carry that name instead. Usually it can, and everyone benefits.

— The AccessWiser Team

Catch label problems before your users do

AccessWiser scans your site against WCAG 2.2 AA, with Section 508 and EN 301 549 mappings, and shows each issue next to the element and criterion it affects. Plans start with Starter at $24 per month, followed by Basic at $49 per month and Pro at $119 per month, and a 7-day free trial lets you see real findings on your own pages first. See the plans and pricing, or explore accessibility solutions for every website. Developers who want to run checks in a pipeline can start with our WCAG 2.2 testing workflow.

FAQ

Should I use aria-label or a visible label?

Use a visible <label> whenever you can. It is seen by everyone, increases the click target, goes through translation with the rest of the page and matches what voice users say. Reserve aria-label for controls with no room for visible text, such as an icon-only button.

Does aria-label work on any HTML element?

No. It is dependable on interactive elements, landmarks and elements with a role that supports naming. On a plain <div> or <span> with no role, results vary between screen readers. Pick a native element or add the right role.

How long should an ARIA label be?

The W3C guidance describes accessible names as typically one to three words. Longer context, like format hints or warnings, goes in a description tied with aria-describedby.

When should I use aria-live?

Use it when content changes without the user moving focus, such as search result counts, cart updates or inline status messages. Start with polite, create the empty region before filling it, and keep the messages short. Use assertive only for urgent errors.

Can a scanner tell me if my labels are good?

It can tell you whether a name exists, which catches many real defects. It cannot judge whether the name is clear or matches the visible text in a way that helps people. That takes a screen reader and speech-input check by a person.