Form inputs without labels: a critical accessibility failure
Every form input needs a <label> programmatically associated with it. Placeholder text and visual proximity don't count — screen reader users can't fill out unlabelled forms. Fix it with for/id or by nesting.
Every form input needs a <label> programmatically associated with it. Placeholder text and visual proximity don't count — screen reader users can't fill out unlabelled forms. Fix it with for/id or by nesting. A form label is <label for="email">Email</label><input id="email">. The for attribute on the label must match the id on the input. Alternatively, nest the input inside the label. Placeholder text is supplemental, never a substitute.
Last updated·
What it is
A form label is <label for="email">Email</label><input id="email">. The for attribute on the label must match the id on the input. Alternatively, nest the input inside the label. Placeholder text is supplemental, never a substitute.
Why it matters
Unlabelled form fields are a WCAG Level A failure and a top reason users with disabilities abandon signup flows. Search engines also use label text as context for what data the form collects, which affects how forms appear in autofill suggestions.
How to fix it
- Pair every input with a real <label>. Either <label for="email">Email</label><input id="email" name="email"> or <label>Email <input name="email"></label>. Both are valid.
- Use aria-label when a visible label isn't possible. For icon-only buttons or search fields with adjacent text: <input aria-label="Search the docs">. Visible labels still win.
- Audit with axe DevTools. The "label" rule catches every unlabelled control. Fix at the component level so new forms don't regress.
Authoritative sources
- Google Search Central documentation — Google
- Schema.org vocabulary — schema.org
- SEO Starter Guide — Google Search Central
- MDN — HTML meta and link elements — Mozilla MDN