Skip to content

Test your website now

Free, no card. We read only public pages.

Run free audit →

Accessibility · WCAG 4.1.2 level A

ARIA Input Fields Must Have an Accessible Name: Label the Widget

Name custom ARIA fields with correct label relationships. Prefer native controls, preserve purpose and value semantics, and test full keyboard interaction.

Published · Updated

What the check tests

Check
a11y.axe.aria-input-field-name - ARIA input fields must have an accessible name
Passes when
Ensure every ARIA input field has an accessible name
Scope
graded on every page crawled
Conformance
WCAG level A
Fix effort
small - under an hour

In one paragraph

ARIA input fields must have an accessible name means a tested custom field role lacks the question or purpose users need to identify it. Connect the widget to an appropriate visible label or another correct naming mechanism. A for attribute does not automatically label an arbitrary div with a textbox role. Naming alone does not implement editing, selection, keyboard behaviour, or form submission.

Why it matters

Custom textboxes, comboboxes, sliders, and other fields need names independently of their values. A selected country or a range value does not tell a user whether it means shipping destination, language, price, or volume.

Native labelable controls support ordinary HTML associations. An arbitrary div does not become labelable through for merely because it has an ARIA input role. The important distinction is the host element's actual labelability and implementation, not a claim that every possible custom element has identical capabilities.

Prefer native controls where they meet the task. A custom widget may be justified, but it introduces obligations for focus, state, required properties, editing or selection, and persistence. A short name test covers only one part of that contract.

How WebAuditOS evaluates this finding

The supplied aria-input-field-name rule checks applicable custom textbox, combobox, listbox, searchbox, slider, and spinbutton roles. Its naming paths include supported ARIA labels or references and title fallback, with exclusions for native controls and specified nested or popup cases.

Serious impact maps to high severity. Placeholder-like text and ordinary contents do not automatically satisfy the documented role naming paths. A hidden or later-created widget may not be tested, and a pass does not confirm agreement with visible wording or correct keyboard behaviour.

How to fix it

  1. Identify the real field role and whether a native input, textarea, select, or range control would meet the need with less custom code. Replacing a custom component requires preserving the actual application function.
  2. For ordinary text entry, prefer a native association such as:
<label for="comment">Comment</label>
<textarea id="comment" name="comment"></textarea>

This is a native alternative, not a way to apply this particular custom-role rule to every form.

  1. Where a custom widget remains necessary, connect its visible label through an appropriate aria-labelledby relationship. Reference real unique IDs and inspect the computed name after rendering, rather than assuming visual proximity is enough.
  2. Use aria-label when an appropriate visible-reference pattern is not available, while evaluating whether all users still receive adequate visible instructions. Keep accessible and visible wording consistent.
  3. Separate name, description, value, and state. A slider needs a meaningful subject and correct range behaviour; a combobox needs its current input, expansion, selection, and popup relationships according to the intended pattern.
  4. Implement the supported keyboard and focus model fully. A custom role does not add native form submission or automatic input validation. Test data persistence and errors as well as announcement.
  5. Exercise empty, selected, open, closed, invalid, loading, and dynamically added states. Popup exclusions in one rule are not permission to leave the complete widget unlabelled or its controls inaccessible.
  6. Rescan and perform manual completion tests with supported input methods and assistive technology. Inspect incomplete results and neighbouring ARIA requirements separately from this name-presence result.

What the fix can break

Replacing a field can change event names, value formats, validation, or submission. Preserve the data contract while simplifying semantics.

Adding an ARIA name can override existing content or native names in ways the developer did not intend. Check computed precedence and maintain consistent visible labels.

Do not use a permanent hidden dummy label merely to silence a warning on a field whose actual question changes. Keep the name tied to the live task and language.

Questions

Does label for automatically name a role=textbox div?

No. An ordinary div is not made natively labelable by that role. Use the appropriate explicit naming relationship or a suitable native control.

Can a value serve as the field's subject?

Not automatically. Users need to know both what the field asks and its current answer or setting.

Does an accessible name implement a combobox?

No. Its complete interaction, state, and relationship pattern still requires implementation and testing.

Review native form labels, toggle names, and select names.

What severity does this get in the report?

High. An axe finding takes its severity from the impact axe reports for the element that failed, and the report maps critical and serious to high, moderate to medium, minor to low. This rule is declared serious in axe-core 4.13.0, so every failure arrives as high.

Standards and sources

In the report

Test this on your own site

Every scan runs a11y.axe.aria-input-field-name on every page it crawls, on every plan. The finding carries this id, so a line in a report can be matched to the explanation above - and the free scan needs no account.