ARIA Input Fields Must Have an Accessible Name: How to Fix It

What this check flags

This rule fires when an element with an input-style ARIA role — textbox, combobox, searchbox, spinbutton, or listbox — ships without an accessible name. A screen reader lands on it and announces something like “edit text, blank,” so the person has no idea what to type. It rarely tanks rankings on its own, but it drags down your Lighthouse accessibility score, and unlabeled inputs are the single most common reason a form gets abandoned by keyboard and assistive-tech users.

Picture a checkout page rebuilt with a custom autocomplete for the shipping address. Sighted users see the “Street address” caption sitting above it, so they type without a second thought. A screen-reader user tabs into the same field and hears “combobox, blank” — nothing ties that visible caption to the widget in the accessibility tree. They can’t tell whether they’re in the name field, the address field, or a coupon box, and a good share of them bail rather than guess. That’s the whole failure in one sentence: a name that exists visually but not programmatically.

A real failing snippet, and the fix

The classic offender is a custom search widget built out of a plain <div> with a role bolted on and nothing to name it:

<!-- FAILS: role=combobox, zero accessible name -->
<div role="combobox" aria-expanded="false" tabindex="0">
  <div role="textbox" contenteditable="true"></div>
</div>

The role tells assistive tech “this is a combobox,” but there is no label text anywhere for it to read. Give it a name. If a visible label exists, point at it with aria-labelledby; if the design has no visible label, fall back to aria-label:

<!-- PASSES: labelledby wires the visible text to the widget -->
<span id="site-search-lbl">Search the catalog</span>
<div role="combobox" aria-expanded="false" tabindex="0"
     aria-labelledby="site-search-lbl">
  <div role="textbox" contenteditable="true"
       aria-label="Search the catalog"></div>
</div>

Honestly, if you can, don’t hand-roll this at all — a native <input type="search"> with a real <label> gets you the name, the keyboard behavior, and the focus handling for free.

Which naming method wins

When more than one naming source is present, the accessible name is resolved in a fixed order. Knowing the precedence stops you chasing a name that a higher-priority source is silently overriding.

Note that aria-labelledby beats aria-label. If a control has both and the name looks wrong, check whether a stale aria-labelledby is winning — it will quietly override the aria-label you thought was in charge, and you’ll swear the fix isn’t taking. This is also why a placeholder is such a trap: it’s dead last in the order, so any of the three sources above it will suppress it entirely, and the moment it does surface, it vanishes as soon as someone types a character.

How to detect it

1. axe DevTools: run a scan and open the “ARIA input fields must have an accessible name” violation. It lists every offending node and highlights it in the DOM so you can jump straight to the element.
2. Lighthouse: run the Accessibility audit in Chrome DevTools; this check appears under the ARIA group with the failing elements enumerated below it.
3. ARIA DevTools / the browser accessibility tree: open the Accessibility panel, select the control, and look at the computed Name field. If it’s empty, the fix hasn’t landed — this is the ground truth a screen reader actually uses.

How to fix it

1. Find the element flagged in your scanner and confirm its role in the accessibility tree.
2. If a visible label is already on the page, add aria-labelledby pointing to that label’s id.
3. If there is no visible label, add a concise aria-label that says what the field is for.
4. Where you can, swap the custom widget for a native input plus a real <label> — it removes the whole class of bug.
5. Re-run the scan and confirm the computed name is now populated.

One habit that saves hours: name the control at the moment you assign it a role, not as a cleanup pass later. The role and the name are a package — the second you write role="combobox", you’ve promised assistive tech there’s a name to go with it. Treat a role without a name as an incomplete component, the same way you’d treat a function that’s missing an argument.

If you build a lot of custom inputs, it’s worth reviewing the related check on required ARIA attributes being provided, since roles like combobox need companion states too. And when the name still won’t compute, the culprit is often a broken reference — make sure every id used in ARIA and labels is unique and actually present in the DOM.

FAQ

Does a placeholder count as an accessible name?

Only as a weak last resort, and some scanners won’t accept it. Placeholders disappear the moment someone starts typing and often fail contrast, so treat them as a hint, not a label.

What’s the difference between this and “Form input elements must have labels”?

That sibling check targets native <input> elements missing a <label>. This one targets elements that declare an input role via ARIA. See form input elements must have labels for the native side of the coin.

Can one label name several inputs?

aria-labelledby can reference multiple ids, and the names concatenate. But if you point several separate controls at the identical label text, you’ll trip duplicate label warnings — keep each control’s name distinct.

My input has a name in the DOM but the check still fails. Why?

Check the accessibility tree, not the DOM. A common cause is an aria-labelledby that points at an id which doesn’t exist, or a label element that is itself display:none in a way that empties the computed name. Also make sure the referenced ids used in ARIA are unique.