Skip to content

Forms & errors

A Custom Input Field Has No Name

A custom text box, slider or dropdown has no name in the code, so screen reader users hear what kind of field it is but not what it's for.

aria-input-field-nameWCAG 2.0Introduced in WCAG 2.0.Level AA — the minimum. Missing it blocks people outright.

Status
SeriousSerious — Significant friction, or information that is lost.CurrentScanners run this rule today.
Owner
DesignDevContentTest
Audit
Automated+ManualA scanner finds it; a person confirms the fix.
Save as PDF (opens in a new tab)

Why it matters

Some teams build their own fields from div elements and add a role, like textbox, slider or combobox. A role says what kind of field it is. It doesn't say what the field is for.

Without a name, a screen reader says only "edit text" or "slider". People can't tell which field is which. They may type the wrong thing, or give up on the form.

Who it affects

Who it affects, and how much
WhoWhat they experienceImpact
Screen reader usersThey hear "edit text, blank" or "slider, 50" with no clue what the field is for.High impact
Voice control usersThey can't say "click Message", so they must use slower number or grid commands.High impact
Low-vision users (magnification)Affected if they also use a screen reader, as many do.Partial impact
Cognitive and neurodivergent usersIf the visible label is also missing or vague, they have to guess what to enter.Partial impact

Business & product impact

Business & product impact, with how much each claim weighs
AreaWhyImpact
LegalIt fails WCAG 4.1.2 at Level A, the minimum. Complaints under Australia's Disability Discrimination Act point to WCAG 2.2 AA, and EN 301 549 has the same test.High impact
ConversionUnnamed fields in checkout, search or sign-up forms stop people finishing. Each one is a lost sale or lead.High impact
SEONo real search benefit — don't sell it as one.Low impact
Brand trustA form people can't fill in feels careless. Screen reader users tell others.Moderate impact
Cost to fixUsually a one-line fix. Fix it once in the shared field component and every form gets it.High impact

Fixing it in code

A custom message box

Don't

<span>Message</span>
<div role="textbox" contenteditable="true"></div>

A screen reader says: “Edit text, blank”

Do

<span id="msg-label">Message</span>
<div role="textbox" contenteditable="true" aria-labelledby="msg-label"></div>

A screen reader says: “Message, edit text, blank”

aria-labelledby links the visible word to the field, so both say the same thing.

A custom volume slider

Don't

<div role="slider" tabindex="0" aria-valuemin="0" aria-valuemax="100" aria-valuenow="50"></div>

A screen reader says: “Slider, 50”

Do

<div role="slider" tabindex="0" aria-label="Volume" aria-valuemin="0" aria-valuemax="100" aria-valuenow="50"></div>

A screen reader says: “Volume, slider, 50”

aria-label gives the slider a name when there's no visible text to point to.

Fixing it in design and content

Write a clear label

Don't

A field labelled only "Enter here".

A screen reader says: “Enter here, edit text”

Do

A field labelled "Delivery address".

A screen reader says: “Delivery address, edit text”

A name only helps if it says what to enter.

Designer's handoff note

Give every field a visible label in the design, not just placeholder text.

If a field truly has no visible label, like a search box beside a magnifier icon, write the hidden name in your spec.

Quick test

Tool

NVDA (opens in a new tab) (free on Windows) or VoiceOver (opens in a new tab) (on every Mac)

Checklist

Pass
Every field announces its purpose, like "Message, edit text".
Fail
A field says only its type, like "edit text" or "slider".

What a green scan still misses

A scanner can tell a field has no name. It can't tell if the name is clear, or matches the label people see on screen.

Reference

Rule ID
aria-input-field-name
Raised by
  • axe-core: “ARIA input fields must have an accessible name”
WCAG
Other standards
EN 301 549 9.4.1.2 · RGAA 11.1.1
Last reviewed
14 October 2026