Home / Knowledge Base / Why ARIA Input Controls Must Have Accessible Names

Why ARIA Input Controls Must Have Accessible Names

ARIA input roles represent interactive controls that accept user input. Because these controls are implemented using generic elements instead of native form controls, they do not receive built-in labelling behaviour.

As a result, authors must explicitly provide an accessible name. If an ARIA input field has no accessible name, assistive technologies cannot identify its purpose, even if the control appears clear visually.

WCAG Success Criterion

Success Criterion 4.1.2 — Name, Role, Value (Level A)

User interface components must have a name and role that can be programmatically determined, and states, properties, and values that can be programmatically set and announced to assistive technologies.

ARIA input roles expose role and state, but do not automatically provide a name.
When an accessible name is missing or invalid, the control fails SC 4.1.2.

Beginner Foundation: What This Rule Is About

What Is an ARIA Input Field?

An ARIA input field is an element that behaves like a form control but is created using ARIA roles instead of native HTML inputs.

This includes elements with the following roles:

  • textbox
  • searchbox
  • combobox
  • listbox
  • slider
  • spinbutton

These roles indicate user input, not presentation.

What Is an Accessible Name?

An accessible name is the text that assistive technologies announce to identify a control.

Examples:

  • “Search currency pairs”
  • “Choose a value”
  • “Enter quantity”

Screen readers rely on the accessible name to answer the user’s most basic question:

What is this control for?

How Screen Readers Use This Information

Browsers build an accessibility tree from the DOM, native semantics, and valid ARIA.

Screen readers announce controls based on:

  • Role (e.g., textbox, slider)
  • Accessible name
  • Current state or value

Typical output:

“Search currency pairs, search box”

Without a name:

“Search box”

Users navigating by form controls (for example, using the F key in NVDA) will encounter an unnamed control with no context.

Required Accessible Names

Per WAI-ARIA 1.2, the following input roles require an accessible name:

  • textbox
  • searchbox
  • combobox
  • listbox
  • slider
  • spinbutton

If these roles do not expose a name, the control is incomplete and non-conformant. Not all ARIA roles behave the same way. Some roles (e.g., button) allow names from content by default. Input roles typically require author-provided names.

How Accessible Names Are Computed

Accessible names are calculated using the Accessible Name and Description Computation algorithm defined in WAI-ARIA 1.2.

At a high level, the algorithm:

  1. Prioritises aria-labelledby
  2. Then aria-label
  3. Then, other allowed sources, depending on the role
  4. Ignores invalid, empty, or broken references

This is not a heuristic. It is a defined algorithm.

How ARIA Input Fields Can Be Named

ARIA input fields may receive an accessible name from:

  • aria-labelledby
  • aria-label
  • Content only if the role explicitly allows name-from-content

⚠️ Critical warning

An empty or whitespace-only aria-label:

aria-label=""
aria-label=" "

Overrides all other naming sources and results in no accessible name, even if visible text or aria-labelledby is present. This is a common production bug.

Correct Markup Examples (Passing)

Combobox

<div id="pass1"
     role="combobox"
     aria-label="Country"
     aria-expanded="false">
  England
</div>

✔ Accessible name is present

Note: This example is simplified to demonstrate naming only.
A fully conformant ARIA 1.2 combobox requires additional structure and relationships.

Listbox using aria-labelledby

<p id="pass2Label">Select a color:</p>
<div id="pass2" role="listbox" aria-labelledby="pass2Label">
    <div role="option">Orange</div>
</div>

✔ Name resolved from referenced text

Searchbox using aria-labelledby

<p id="pass3Label">Search currency pairs:</p>
<div id="pass3"
     role="searchbox"
     contenteditable="true"
     aria-labelledby="pass3Label"></div>

✔ Accessible name is programmatically determined

Slider with explicit name

<div id="pass4"
     role="slider"
     aria-label="Choose a value"
     aria-valuemin="1"
     aria-valuemax="7"
     aria-valuenow="2"></div>

✔ Name and value exposed

Spinbutton with explicit name

<div id="pass5"
     role="spinbutton"
     aria-valuemin="0"
     aria-valuemax="10"
     aria-valuenow="8"
     aria-label="Enter quantity"></div>

✔ Name is present and descriptive

Textbox using aria-labelledby

<label id="foo">
  Foo
  <div id="pass6" role="textbox" aria-labelledby="foo"></div>
</label>

✔ Name resolved via ID reference

Incorrect Markup Examples (Failing)

Empty aria-label overrides everything

<div role="textbox" aria-label=" "></div>

✖ No accessible name

Broken aria-labelledby

<div role="combobox" aria-labelledby="missing-id"></div>

✖ Referenced element does not exist

<label> does not label generic elements

<label>
  First name
  <div role="textbox"></div>
</label>

✖ Implicit labels apply only to native form controls

<label for> with non-labelable element

<label for="name">First name</label>
<div id="name" role="textbox"></div>

✖ Explicit labels do not apply to generic elements

Description without a name

<p id="hint">Enter your username</p>
<div role="textbox" aria-describedby="hint"></div>

✖ Has a description, but no accessible name

aria-describedby does not provide a name.

Native HTML vs ARIA

Native form controls automatically support labelling:

<label for="email">Email</label>
<input id="email">

ARIA input roles do not receive this behavior automatically.

When replacing native inputs with ARIA:

  • You must provide the name explicitly
  • Incorrect ARIA can override correct native behaviour
  • Invalid ARIA is often worse than no ARIA

Why This Matters

Without an accessible name:

  • Screen reader users cannot identify the purpose of the control
  • Navigation by form controls becomes unreliable
  • Users must guess or abandon the interaction

This is a direct failure of Name, Role, Value.

How This Is Tested

Audits verify that:

  • Each ARIA input role resolves to a non-empty accessible name
  • Name computation follows the AccName algorithm
  • Referenced IDs exist and contain readable text

Automated tools can detect missing or empty names.
Manual testing confirms whether the name is meaningful in context.

How to Fix the Problem

  • Provide a valid accessible name using aria-labelledby or aria-label
  • Ensure referenced IDs exist, are unique, and visible to AT
  • Avoid empty aria-label values
  • Do not rely on <label> with non-native controls
  • Prefer native HTML inputs whenever possible

Wrapping Up

ARIA input roles represent form controls, and form controls must have names. ARIA does not generate accessible names automatically for input roles. If authors do not provide one, assistive technologies have nothing to announce. When an ARIA input field has no accessible name, it is functionally unusable for screen reader users and fails WCAG 4.1.2.

Want to test against all WCAG success criteria?

Stay compliant. Avoid fines. WebYes reviews your entire website so you don't have to worry.

Sign Up for Free Now