How to fix: placeholder used as label

What it looks like in the wild

Once typing starts, the field has no visible label.

The screen-reader user, keyboard user, or low-vision user encountering this issue does not get an error message. The page just stops working for them. Which is why this kind of bug rarely shows up in your error tracker; it shows up in support tickets, lawsuits, and abandoned conversions.

Why it fails WCAG

Cognitive and screen-reader users lose context.

The wrong pattern (avoid)

<input type="text" placeholder="First name">

The right pattern (copy this)

<label for="fn">First name</label>
<input id="fn" type="text" autocomplete="given-name">

Notes from real audits

• Float-label patterns are acceptable if the visible label remains.

How to verify the fix

Shipping the change is not the same as passing 3.3.2. Re-run these checks against the page you edited before you close the ticket.

• Empty every input; the label must remain visible.

What 3.3.2 requires

3.3.2 Labels or Instructions (Level A, Understandable): Labels or instructions must be provided when content requires user input. Placeholder-only inputs lose their label as soon as the user starts typing — and screen readers vary on whether they announce them at all. Visible labels are the WCAG-compliant default.

• Placeholder used as label

  3.3.2

• Required-field markers shown only with color

  3.3.2

• Date format unstated

  3.3.2

Priority: Serious

This is one of the findings that shows up in demand letters, because the barrier it creates is total rather than inconvenient: the affected user cannot complete the task at all. Treat it as a release blocker, not a backlog item.

Because the cause is almost always a shared component rather than a single page, fix it where the component is defined and re-scan the whole site. Record 3.3.2 on the ticket verbatim: that string is what an auditor, a procurement questionnaire or a regulator will search for.