How to fix form fields without labels

WCAG 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value require every form control to have a programmatic label, so assistive technology can announce what the field is for. The usual culprits:

• Using a placeholder instead of a label (it disappears when typing and is not a reliable accessible name).
• A visible label that is not associated with its input.
• Icon-only or search fields with no text at all.

Both mean the control has no programmatic label: nothing connects any text on the page to that input, so a screen reader announces the field type and nothing else. "Edit, blank" tells the user there is a box, not what belongs in it.

"Form elements must have labels" is axe-core's wording, which is what this scanner, Chrome DevTools and PageSpeed Insights all report. "No label associated with a form field" is the same finding phrased around the missing association, and that word is the important one: a label sitting visually next to an input is not associated with it unless for matches the input's id, or the input is nested inside the <label>.

This one is a real conformance failure. axe maps it to 4.1.2 Name, Role, Value at Level A, and the visible-label side is covered by 3.3.2 Labels or Instructions.

A programmatic label with no visible text is enough to pass. A search field named by aria-label="Search products", or by a visually hidden <label>, satisfies 4.1.2 and 1.3.1. Both put a real name in the accessibility tree, which is what those criteria ask for.

The catch is who benefits. A hidden label serves screen-reader users and does nothing for a sighted user with a cognitive or memory difficulty, who has only the field's position and a magnifying-glass icon to go on. 3.3.2 Labels or Instructions asks for a label or instruction when input is required, so relying on a hidden one is a judgement call rather than a free pass. A single search box beside a search button is the widely accepted case for it. A checkout form is not.

Two things that are not equivalent to a hidden label: a placeholder, which vanishes the moment someone types and is announced inconsistently, and a title attribute, which depends on hover and is skipped by some assistive technology. If you use either, add a real label as well.

If you do hide a label visually, hide it with a clip-based utility class rather than display: none or visibility: hidden, since those remove it from the accessibility tree along with the pixels and put you back where you started.

Associate a real <label> with the input by matching for to the input's id:

<label for="email">Email address</label>
<input id="email" type="email" name="email">

Wrapping also works: <label>Email <input type="email"></label>. When there is no visible label by design (for example a search field with a button), give it an accessible name instead:

<input type="search" aria-label="Search products">

You can keep a placeholder as a hint, but it must be in addition to a label, never instead of one.

Forms tend to live in more places than people remember: the newsletter box in the footer, the search field in the header, a filter panel, the checkout. The scan above lists every control with no label and shows the exact element, so you are not relying on memory. Fix the markup and scan again. If forms get added often, the GitHub Action can fail a pull request that adds an unlabelled one.