How to give ARIA fields, toggles and dialogs an accessible name?

aria-input-field-name page

The issue

A screen reader announces “edit text”, “checkbox, not checked” or “dialog” and stops there. The user can’t tell what to type, what they are agreeing to, or what the dialog is about, and has to guess from whatever they happen to read next. A progress bar with no name reports a number with no subject.

The cause is a field, toggle or widget with no accessible name: no <label>, no aria-label, no aria-labelledby pointing at visible text. It is common in custom components built from <div> elements with a role, and in native fields whose visible label isn’t connected to them. WCAG 4.1.2 requires every user interface component to have a name.

Scope

Seven rules cover different roles with the same test. Each checks visible elements whose role, written in a role attribute or coming from the element itself, is in its list.

Native elements count: a text <input>, <textarea> and <select> are input fields, a checkbox or radio <input> is a toggle, <progress> is a progress bar and <dialog> is a dialog. Probeo takes a name from aria-labelledby, aria-label, an associated <label>, a field’s placeholder, a title, or the element’s own text. Buttons and links are covered by accessible names instead.

How to check you have it

• In probeo: the page reports the rule for the role, with serious impact. The messages are:
  • aria-input-field-name: “ARIA input fields must have an accessible name”
  • aria-toggle-field-name: “ARIA toggle fields must have an accessible name”
  • aria-meter-name: “ARIA meter elements must have an accessible name”
  • aria-progressbar-name: “ARIA progressbar elements must have an accessible name”
  • aria-tooltip-name: “ARIA tooltip elements must have an accessible name”
  • aria-treeitem-name: “ARIA treeitem elements must have an accessible name”
  • aria-dialog-name: “ARIA dialog and alertdialog elements must have an accessible name”
• By hand: focus each field and widget with a screen reader on and listen for a name. For dialogs, open them and listen to what is announced first.
• With a tool: axe DevTools reports the same rule ids. The accessibility pane in Chrome or Firefox DevTools shows each element’s computed name.

<label for="email">Work email</label>
<input id="email" type="email">

<div role="switch" aria-checked="false" tabindex="0" aria-labelledby="sw-label"></div>
<span id="sw-label">Email me about new issues</span>

<dialog aria-labelledby="dlg-title">
  <h2 id="dlg-title">Delete this site?</h2>
  …
</dialog>

FAQ

Why does a native <input> fail an ARIA rule?

The rules check roles, and native elements have roles of their own: a text input is a textbox. An input with no label fails both this rule and the form labels check. One <label> fixes both.

Probeo passed my dialog, but it has no aria-labelledby. Is it fine?

Not necessarily. Probeo accepts the dialog’s own text as its name, which is a simplification. Screen readers generally don’t name a dialog from its content, so point aria-labelledby at its heading anyway.

Does a placeholder count as a name?

Probeo accepts it as a last resort, so a field with only a placeholder passes. It is still a weak label: it vanishes on input, often has low contrast, and isn’t read consistently. A visible <label> is the dependable choice.