ARIA input field has no accessible name

What is this issue?

An element carrying role="textbox", role="combobox", or role="searchbox" has no accessible name: the text a screen reader announces to identify an element. It comes from the first source that applies, in order: aria-labelledby, aria-label, visible label text, then other fallbacks specific to the element type.

Unlike a native <input>, these ARIA roles have no built-in association with a <label> element. If the widget doesn’t have aria-label or aria-labelledby pointing at real text, its role is announced but nothing about its purpose is: the field is a blank slot with no indication of what belongs in it.

Why does this matter?

Custom input widgets (a rich-text editing surface, a contenteditable search box styled to match a design system, an autocomplete combobox) exist because a native <input> couldn’t do exactly what the design needed. But that trade means the widget loses the label mechanism native inputs get for free, and that has to be rebuilt deliberately with ARIA.

When it isn’t, a screen reader user tabbing into the field hears its role and nothing else. For a search box, that’s a mild annoyance: the purpose is usually guessable from context. For a combobox in the middle of a multi-step checkout form, a user with no idea what the field expects either guesses and risks an error, or abandons the form rather than fill in an unknown field blind.

Who is affected?

• Screen reader users: hear a bare role (“edit text,” “combo box”) with no purpose attached, and have to explore the surrounding page or guess from context what belongs in the field.
• Voice control users: target a field by speaking its accessible name, such as “click Search.” With no name to match, voice software can’t address the widget at all, even though it’s fully visible and interactive on screen.

What users experience

Renee uses NVDA on her Windows laptop to book a hotel through a travel site. The destination field is a div with role="combobox" powering an autocomplete dropdown, and it has no aria-label. NVDA announces “edit, combo box” as she tabs into it, with no hint that it wants a city name. She types a guess, gets no suggestion dropdown she can confirm is even open, and switches to the phone booking line instead of risking an incorrect reservation.

How do I fix it?

Add aria-label with a short description of what the field expects, such as aria-label="Search products" or aria-label="Destination city". This works because aria-label supplies a name directly to the accessible name computation with no dependency on visible markup structure, which fits custom widgets that rarely have a native <label> association available.

When descriptive text already exists visibly on the page (a heading directly above the widget, or a caption inside the same component), use aria-labelledby pointing at that element’s id instead. This reuses text that’s already there, so sighted and non-sighted users read the exact same name with nothing to keep in sync manually.

Where the design doesn’t strictly require a custom widget, prefer a native <input>, <select>, or <textarea> connected to a real <label>. Native controls keep the label mechanism, keyboard behavior, and browser autofill working without any ARIA at all.

Code Examples

<div role="searchbox" contenteditable="true"></div>

<!-- Method 1: aria-label (no visible text exists to reuse) -->
<div role="searchbox" contenteditable="true" aria-label="Search the site"></div>

<!-- Method 2: aria-labelledby (a visible caption already exists) -->
<span id="search-caption">Search articles</span>
<div role="searchbox" contenteditable="true" aria-labelledby="search-caption"></div>

Method 1 gives assistive technology a name directly, useful when the widget’s compact design leaves no room for visible text. Method 2 reuses text already on the page, so there’s only one string to keep accurate instead of two that could drift apart.

Common Mistakes

Mistake: “The placeholder text inside the widget explains what it’s for.” A placeholder-style hint rendered with CSS or JavaScript inside a custom widget is not the same as the native placeholder attribute, and neither one is an accessible name. It disappears once the user starts typing and often isn’t exposed to assistive technology at all in a hand-built widget; it needs aria-label or aria-labelledby regardless.

Mistake: “It’s a search box, so its purpose is obvious without a label.” Purpose being obvious to a sighted user who sees a magnifying-glass icon next to the field says nothing about what a screen reader announces. The icon isn’t read as text unless it also carries aria-hidden="true" and the field itself has aria-label; visual convention and accessible name are unrelated.

Mistake: “I gave the widget an id, so it’s associated with the label near it.” An id alone does nothing for accessible naming. Only aria-labelledby="that-id" (placed on the widget and pointing back at the labelling element’s id) creates the association; the id sitting unused on the label text does nothing on its own.

How RedFlag Detects This

Automated: axe-core rule, runs on every scan. RedFlag calls axe-core’s aria-input-field-name rule as part of every scan, restricted to the WCAG 2.0/2.1/2.2 A and AA rule set. The rule selects every element with role textbox, combobox, or searchbox and checks whether the accessible name computation resolves to non-empty text.

False negative: axe-core confirms a name exists but can’t judge whether it’s accurate. A combobox labelled aria-label="Field" passes automatically, even though it tells the user nothing about what to enter. False positive: none typical for this check, since resolving to a non-empty accessible name is a binary condition. Manual step: read the announced name for each custom input and confirm it actually describes the expected value, not just that a name exists.

Manual Testing

1. Open the page in Chrome or Firefox with NVDA or VoiceOver running.
2. Tab into every custom textbox, combobox, or searchbox on the page: anything built as a div or span rather than a native form control.
3. Listen to what’s announced right after the role: it should be a specific purpose (“Destination city, combo box”), not the role alone (“combo box, blank”).
4. If the widget opens a dropdown of suggestions, confirm the announcement updates appropriately as options appear, not just on initial focus.
5. Repeat with VoiceOver on a Mac to confirm the name reads consistently, since custom widgets sometimes behave differently across screen readers depending on how their ARIA is wired.

Related WCAG Success Criteria

4.1.2 Name, Role, Value: Every interface component must expose a name, role, and current value to assistive technology. A custom input role with no accessible name has a role and, once the user types, a value, but no name, which is the specific gap this criterion requires closing.

3.3.2 Labels or Instructions: Labels or instructions must be provided when content requires user input. A custom input widget is still user input; this criterion applies whether the field is a native <input> or an ARIA-role div, and this rule is one way of failing it on the custom-widget side specifically.

Related Issues

ARIA command has no accessible name covers the same missing-name failure for button, link, and menuitem roles: the same underlying naming problem on action-triggering widgets instead of data-entry ones.

Form input has no label is the native-HTML twin of this rule: the identical failure on a real <input>, <select>, or <textarea> instead of a custom ARIA role.

Input only uses placeholder as its label covers a related pitfall on native inputs: relying on placeholder text as if it were a real label, the same mistake writers of custom widgets sometimes make with a fake placeholder rendered in CSS.

ARIA toggle field has no accessible name is the equivalent failure for checkbox, radio, and switch roles, which announce state rather than accept typed or selected input.

References

• W3C Understanding 4.1.2: Name, Role, Value
• ARIA Authoring Practices: Combobox Pattern
• MDN: ARIA textbox role