Labelling form fields

4.1.2 Name, Role, Value · Level A W3C: Understanding 4.1.2

The sample email field has only placeholder text. Placeholders vanish when typing starts, are often low contrast, and are not reliably announced as the field's name, so the field fails 4.1.2 and, for the visible instruction, 3.3.2 Labels or Instructions.

Who this affects: People who use screen readers or voice control, people with memory or attention difficulties, and anyone returning to a half-filled form.

The failing markup

<form action="/subscribe">
  <input type="email" name="email" placeholder="Email address">
  <button type="submit">Subscribe</button>
</form>

How to fix it

Add a visible <label for> pointing at the input's id. The label also makes the text clickable, enlarging the target.
Add autocomplete with the right token, such as autocomplete="email", so browsers can fill the field.
Keep a placeholder only for an example format, never as the label.

The change

  <form action="/subscribe">- Removed:   <input type="email" name="email" placeholder="Email address">+ Added:   <label for="email">Email address</label>+ Added:   <input type="email" id="email" name="email" autocomplete="email">    <button type="submit">Subscribe</button>  </form>

Verified by the scanner

On 2026-09-13 both versions of this sample were run through Accessibility Pro's scan pipeline with arc-style, axe-core, ibm-equal-access, pa11y, focus-graph. The failing markup was reported as:

arc-style: input-label-placeholder-only, WCAG 1.3.1
pa11y: HTML_CodeSniffer check, WCAG 4.1.2

The fixed markup produced no findings at all. To run the same check on every pull request, use the accessibility GitHub Action; how accurate the scanner is overall is in the published benchmark.

Worth knowing

A label wrapped around the input, <label>Email <input></label>, also works and needs no id.