ARIA input field without a name (aria-input-field-name)

The aria-input-field-name rule flags custom input widgets – elements given a role such as combobox, textbox, listbox, searchbox, slider or spinbutton – that have no accessible name. A screen reader then announces "combo box" or "edit text" and nothing about what it is for. The fix is aria-labelledby pointing at the visible label, or aria-label where there is none.

What the rule means

Native fields get their name from a <label>. A <div> with role="textbox" does not: HTML's <label for> only labels real form controls, so a custom widget has to be named with ARIA. The rule passes an element with one of those six roles when it has:

• aria-labelledby pointing at an element with text in it,
• aria-label with text in it,
• or a title attribute.

Native <input>, <select> and <textarea> are not checked here – undefined and undefined cover them. Neither is a listbox that is the pop-up of a combobox, or a combobox that wraps a real <input>.

One case axe does not decide on its own: a <label> associated with a custom element whose accessible name does not include the label text. The label may look connected and still not reach assistive technology, so axe returns the element as "needs review". Whether a name that is there is also meaningful – "field", "input 3" – is a judgement too, which is why the fact box above says "partly".

Who is affected

Blind people using a screen reader, who hear a role with no name and have to guess what to type or choose. Voice-control users, who cannot address a field by a name it does not have. People using a braille display, where the name is the only thing shown for the control.

Why the check fails

• Component libraries whose combobox, date picker or tag input takes a label prop that was left empty.
• Rich-text editors – a contenteditable area with role="textbox" and the heading above it as the only label.
• Custom range sliders for prices or quantities, built from <div>s with role="slider".
• <label for> pointing at a <div> – it looks right in the markup and names nothing.
• Search suggestions built as a custom searchbox in the header, with only a magnifying-glass icon.
• Hand-built "select" replacements in themes, where the visible label is a sibling <span>.

How to fix it

1. First ask whether you need the custom widget. A native <input>, <textarea>, <select> or <input type="range"> gets its name from a <label> and brings keyboard support with it.
2. If you keep it, give the visible label an id and point aria-labelledby at it. Use aria-label only where there is no visible text.
3. Fix it in the component, so every instance gets a name.

<!-- Before: custom fields with visible text nearby, but no name -->
<p class="field-title">Your message</p>
<div class="editor" role="textbox" aria-multiline="true" contenteditable="true"></div>
<span class="field-title">Delivery city</span>
<div class="city-picker" role="combobox" aria-expanded="false" tabindex="0">Berlin</div>

<!-- After: aria-labelledby points each field at its visible label -->
<p class="field-title" id="message-label">Your message</p>
<div class="editor" role="textbox" aria-multiline="true" contenteditable="true"
     aria-labelledby="message-label"></div>
<span class="field-title" id="city-label">Delivery city</span>
<div class="city-picker" role="combobox" aria-expanded="false" tabindex="0"
     aria-labelledby="city-label">Berlin</div>

Naming a widget is not the whole job: a custom combobox also needs the keyboard behaviour and the states (aria-expanded, aria-activedescendant) described in the ARIA Authoring Practices Guide ^[4].

How to test it manually

1. Select each custom field in your browser's accessibility inspector (Chrome, Edge, Firefox). The "Name" should match the visible label.
2. With a screen reader (NVDA on Windows, VoiceOver on macOS), Tab to the field and listen: role and name, such as "Delivery city, combo box".
3. Check the widget with the keyboard alone: can you open, move through and close it? That part no name check covers.
4. Try voice control, for example Voice Access on Windows or Voice Control on macOS: say "click" followed by the visible label.

Related WCAG criterion

4.1.2 Name, Role, Value, Level A: every user interface component needs a name that assistive technology can read. Related: 1.3.1 Info and Relationships, because the link between the visible label and the field has to be in the code, and 2.5.3 Label in Name – the name must contain the words of the visible label.

How Reviseberg reports it

Reviseberg runs aria-input-field-name on every crawled page at 1280px. The issue list shows the rule with its severity, WCAG criterion and level, the number of elements and pages affected, and the points you get back by fixing it. The detail view gives the CSS selector, the HTML snippet and every page affected.

Where axe cannot decide – a <label> that seems to belong to the widget but does not reach its name – the case goes to the Potential issues queue for a person to decide, instead of being counted as a pass. You can mark findings as "ignore", "can't fix" or "false positive" with a reason; every decision is logged.

Related rules

• undefined – native text fields, checkboxes and radio buttons without a name.
• undefined – native <select> drop-downs without a name.
• undefined – a role such as combobox or slider without the attributes it requires.
• undefined – ARIA attributes with a value that is not allowed, such as aria-expanded="yes".

Check the custom widgets on your site – get a free scan