Placeholder Text Is Not a Label: WCAG 3.3.2 and the Vanishing Hint

A placeholder is a hint that disappears the moment someone types. A label is a contract that stays visible and is announced by screen readers. Use a real label element tied to the field, and keep the placeholder, if you want one, for an example value only.

The field with no name

There is a form I keep meeting in audits. Twelve fields, no labels, just placeholder text inside each input that disappears the moment you start typing. To a sighted user glancing at an empty form, it looks finished. To a screen reader user, the field has no name at all: tab to it and hear "edit text, blank", with no indication of what goes in it. That is the placeholder trap, and it is the most common labeling failure on the web. WebAIM's 2026 scan of a million home pages found missing form labels on 51 percent of them, and the placeholder used as a label is the usual cause.

The reasons are mechanical, not philosophical. Placeholder text disappears on input, so a shopper who forgets what the field asked cannot check it. It is usually light gray, often below the contrast minimum, so low-vision users cannot read it even before it vanishes. And screen readers handle it inconsistently: some announce it, some do not, and none treat it as the field's label. WCAG covers it at two criteria, 3.3.2 Labels or Instructions at Level A, which requires a label or instruction when content needs user input, and 4.1.2 Name, Role, Value, which requires the control to have a programmatically determinable name. A placeholder-only field fails both.

The fix, and what the placeholder is for

Give each field a visible label element, connected to the input through the for attribute matching the input's id. The quick test: click the visible label and focus should move into the field. If the layout cannot fit a visible label, hide a real label with a CSS clip pattern, never with display none, which removes it from the accessibility tree too. Or use aria-label when there is genuinely no visible text to point at, though a visible label is always the first choice.

Keep the placeholder, if you like it, for what it is good at: an example of a valid value. "name@example.com" inside an email field, or "MM/YY" inside an expiry field. That is a hint, not a name, and it should never duplicate the label text. A placeholder that says "Email address" where the label also says "Email address" is redundant before typing and absent after. A placeholder that says "name@example.com" is useful in exactly the window where it is visible, and harmless once it is gone. The label does the naming. The placeholder does the example. Confusing the two is how a form ends up with twelve fields and no names. The same forms hide other traps: the modal focus trap and color alone saying error under 1.4.1.

Frequently asked questions

Is placeholder text a label?

No. It disappears on typing, is usually low contrast, and is not reliably announced as the field's name. WCAG and every accessibility guide are clear: a placeholder is not a substitute for a label.

Does an unlabeled field fail WCAG?

Yes, at Level A. It fails 3.3.2 Labels or Instructions and 4.1.2 Name, Role, Value, the most basic conformance level in the standard.

What if the design has no room for a visible label?

Use a visually hidden real label with a CSS clip pattern, or aria-label when there is no visible text to reference. Do not fall back to placeholder-only, and never use display none, which removes the label from the accessibility tree.

Can I keep the placeholder at all?

Yes, as an example value: name@example.com in an email field, MM/YY in an expiry field. It should never repeat the label text, and the field must work perfectly without it.