Why Form Controls Must Have Accessible Names

All user-operable form controls must have an accessible name that identifies their purpose. An accessible name is the text a screen reader announces to identify a control (for example: “Email address, edit text”). Without it, assistive technology users cannot determine what information is expected.

WCAG Success Criteria

1.3.1 — Info and Relationships (Level A)

Information, structure, and relationships conveyed through presentation must be programmatically determined or available in text. Labels provide the programmatic relationship between descriptive text and form controls.

3.3.2 — Labels or Instructions (Level A)

Labels or instructions must be provided when content requires user input. Form fields must clearly identify what input is required.

4.1.2 — Name, Role, Value (Level A)

User interface components must have a name and role that can be programmatically determined. Form controls require an accessible name to satisfy this criterion.

Beginner Foundation: Key Concepts

What Is an Accessible Name?

An accessible name is the primary text that assistive technologies use to identify a control. For example, when focus moves to a text input, a screen reader might announce:

“First name, edit text”

“First name” is the accessible name.

What Does “Programmatically Associated” Mean?

Programmatically associated means the relationship exists in the HTML code, not just visually on the screen.

Screen readers do not infer meaning from layout, spacing, or proximity.
They rely on explicit relationships such as:

<label for="first">First name</label>
<input id="first">

What Does “User-Operable” Mean?

A user-operable control is any element that accepts user input or triggers an action, including:

• Typing text
• Selecting options
• Submitting a form
• Toggling a setting

If a user can interact with it, it needs an accessible name.

What This Rule Is Teaching

This rule explains how users understand forms, not just how tools flag errors. Its goal is to ensure every form control clearly answers this question for assistive technology users:

What is this field for?

Form Controls That Require Labels

All user-operable form controls require an accessible name, including:

• input (except type="hidden")
  • text, email, number, search, tel, url, password, date, file, etc.
• textarea
• select
• checkbox and radio
• button without visible text
• Image submit buttons (input type="image")
• Custom widgets using ARIA roles (e.g., role="textbox")

Exceptions

• input type="hidden" (not user-operable)
• Buttons with visible text (their text provides the name)

How Accessible Names Are Calculated

Accessible names are computed using the Accessible Name and Description Computation algorithm.

In simplified priority order:

1. aria-labelledby
2. aria-label
3. Associated <label> element
4. Element text content (for elements like <button>)
5. placeholder (in some cases, inconsistently)
6. title (limited and unreliable)

Example: Priority in Action

<label for="email">Email</label>
<input id="email" aria-label="Primary email">

Accessible name announced:

“Primary email”

aria-label overrides the <label>.

Correct Labelling Methods (Ordered by Robustness)

1. Explicit <label for> (recommended)

<label for="firstname">First name</label>
<input id="firstname" type="text">

• Most robust
• Largest clickable target
• Clicking the label focuses the input (important for motor accessibility)

2. Implicit Label (Wrapping)

<label>
  First name
  <input type="text">
</label>

Valid and accessible, but less flexible for complex layouts.

3. aria-labelledby (Advanced Layouts)

<div id="firstname">First name</div>
<input type="text" aria-labelledby="firstname">

Multiple IDs are allowed:

<div id="temperature">Temperature</div>
<div id="low">Low</div>

<input type="text" aria-labelledby="temperature low">

Accessible name becomes: “Temperature Low”

4. aria-label (Last Resort)

<input type="text" aria-label="Search">

• Provides an accessible name
• No visible label
• Use only when a visible label is not possible

5. placeholder (Discouraged)

<input type="text" placeholder="Search">

• May contribute to the accessible name in some browsers
• Disappears on input
• Inconsistent across assistive technologies
• Fails usability expectations and WCAG 3.3.2 when used alone

Do not rely on placeholder text as the sole label.

Grouping Related Controls

Radio buttons and checkboxes that form a logical group must be grouped using <fieldset> and <legend>.

<fieldset>
  <legend>Shipping method</legend>
  <label><input type="radio" name="ship"> Standard</label>
  <label><input type="radio" name="ship"> Express</label>
</fieldset>

Screen readers announce the legend before each option, preserving context.

Without a legend, users hear options without knowing what they relate to.

Icon-Only and Image-Based Controls

Icon-Only Button

<button aria-label="Search">
  <svg aria-hidden="true">…</svg>
</button>

Visible icon ≠ accessible name.

Image Submit Button

<input type="image" src="search.png" alt="Search">

Without alt, the button has no accessible name.

Required Fields and Instructions

Use semantic indicators, not symbols alone:

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

Screen readers automatically announce “required”.

Avoid relying solely on visual indicators like *.

Labels vs Descriptions

• Label → accessible name
• Description → supplementary information

<label for="email">Email address</label>
<p id="hint">We will not share your email.</p>
<input id="email" aria-describedby="hint">

A control must have a label even if it has a description.

Error Messages (Real-World Integration)

<input
  id="email"
  aria-describedby="email-hint email-error">

• Multiple IDs allowed
• Order matters
• Error text should be added/removed dynamically

Custom Controls: A Strong Warning

If you build a custom control (e.g., div role="textbox"):

• You must provide a label
• You must support keyboard interaction
• You must manage focus and states correctly

If you cannot fully replicate native behavior, do not build custom form controls. Native HTML inputs are almost always the better choice.

How Screen Readers Use Labels

With a label:

“First name, edit text”

Without a label:

“Edit text”

That difference is not cosmetic. It is context.

How This Is Tested

• Automated tools detect missing or broken label associations
• Manual testing verifies clarity and usability
• Screen readers confirm correct announcements and grouping

How to Fix the Problem

• Ensure every user-operable control has an accessible name
• Prefer <label for> whenever possible
• Group related controls with <fieldset> and <legend>
• Do not rely on placeholder text
• Use aria-label only when necessary
• Keep labels and help text distinct

Wrapping Up

Form controls are usable only when users know what they are for. Labels provide that information programmatically, not visually. Without them, assistive technologies cannot reliably expose form intent. If a control accepts user input, it must have a clear, accessible name.