Missing Form Labels: Why Placeholder Text Isn't Enough
A sighted user glancing at a signup form sees "Email" written just above a text box and understands the connection instantly — the visual proximity does the work. A screen reader doesn't see proximity. It needs an actual, programmatic association between the label text and the input, or it announces the field as nothing more than "edit text" with no indication of what to type.
This is the second most-cited issue in ADA web accessibility lawsuits — around 72% of complaints reference it, right behind missing alt text.
Why placeholder text doesn't fix this
Placeholder text (the greyed-out hint inside an empty input) is often mistaken for a label, but it fails on two counts: it disappears the moment the user starts typing, so anyone who gets interrupted loses the context, and — more importantly for this specific violation — some screen reader and browser combinations don't reliably announce placeholder text as the field's name at all. A placeholder attribute is not a substitute for a <label>.
How to fix it
The most robust fix is an explicit <label> with a for attribute matching the input's id:
<!-- Before: visually looks fine, announces as "edit text" -->
<span>Email address</span>
<input type="email" name="email">
<!-- After: programmatically associated -->
<label for="email">Email address</label>
<input type="email" id="email" name="email">
Wrapping the input inside the label works too, and doesn't require matching an id:
<label>
Email address
<input type="email" name="email">
</label>
When a visible label genuinely isn't part of the design (a search icon-only field, for instance), use aria-label to give it an accessible name without changing the visual layout:
<input type="search" name="q" aria-label="Search the site">
<select> elements need the exact same treatment — a dropdown with no associated label has the identical problem as a text input.
A related failure: the title-only label
Some forms use the title attribute alone (no visible label, no aria-label) to name a field. This technically gives assistive technology something, but WCAG treats title-only labeling as insufficient on its own — title text is inconsistently announced across screen readers and disappears the moment there's no visible on-screen text to match it against, so a sighted user and a screen reader user end up with a different understanding of the form.
Confidence on this fix is high — once a field's purpose is clear from its surrounding context, associating a label is close to mechanical. This is one of the violations AllyProof's AI fix suggestions handle with the most reliability.
Official references
Common questions
- Why isn't placeholder text a valid label?
- Placeholder text disappears as soon as the user types, usually has poor contrast, and is not reliably announced as the field's name by assistive technology. It is a hint, not a label.
- How do I properly label a form field?
- Associate a `<label>` with the input via matching `for` and `id`, wrap the input inside the `<label>`, or use `aria-label`/`aria-labelledby`. A visible `<label>` is best because it helps everyone.
- Which WCAG rules require form labels?
- SC 1.3.1 (Info and Relationships), 3.3.2 (Labels or Instructions), and 4.1.2 (Name, Role, Value), all Level A. axe-core flags them under `label` and `select-name`.
Related articles
Want to see how your own site scores?
Run a free accessibility scan