Form Labels: Why Placeholder Text Is Not a Label

The placeholder looks like a label. It sits inside the field, it says Email address, and it disappears the moment the user starts typing, which is exactly when the user needs it most. A placeholder is not a label, and a form built on placeholders fails WCAG in three different ways at once.

What a label does that a placeholder cannot

A label is a programmatic association between text and a field. The label element, linked to the input by its for attribute, tells assistive technology what the field is for, and it tells the browser that clicking the label focuses the field. Success Criterion 1.3.1, Info and Relationships, requires that association to be programmatic, and Success Criterion 3.3.2, Labels or Instructions, requires labels or instructions for every field that needs user input. A placeholder satisfies neither, because it is not associated with the field in the accessibility tree, and it is not a label in any sense the standard recognizes.

The practical failure is visible to everyone, not just screen reader users. A user who starts typing, gets distracted, and looks back at the form sees a row of filled fields with no indication of which is which. A user with a cognitive disability, or anyone filling a long checkout on a phone, loses the field's purpose the moment the placeholder vanishes. The floating label pattern, where the placeholder animates up to become a label above the field, is the one version of this idea that works, because the text survives as a real label once the field is filled.

Contrast is the third failure. Placeholder text is rendered in a light gray by default in most browsers, and that gray routinely falls below the 4.5 to 1 contrast ratio that Success Criterion 1.4.3 requires for text. A field whose only instruction is light gray text on a white background is a field many low-vision users cannot read before they even start typing. Our own testing has found placeholder contrast failing on checkout forms more often than any other single defect. Related reading: Testing Contrast in Disabled Buttons, Sold Out Options, and Placeholder States.

The patterns that pass

The simplest passing pattern is a visible label above every field, associated with a label element. It is also the most usable, because the label is always visible, always readable, and always clickable. A label above the field, a hint below it for format guidance, and an error message next to it when validation fails is the complete pattern, and it has been the complete pattern for twenty years. More on this: Testing Contrast in Sale Countdown Timers and Urgency Badges.

For space-constrained designs, the floating label is the acceptable compromise, provided the floated text is a real label element and not a styled placeholder. The test is simple: turn off CSS and check whether the label is still there, and inspect the accessibility tree to confirm the field has an accessible name. If the name comes only from the placeholder attribute, the field has no label.

Hidden labels, using aria-label or a visually hidden label element, pass the programmatic test but fail the usability one for sighted users. They are the right choice for a search box with a visible magnifier icon and no room for text, and the wrong choice for a checkout form where every field needs its purpose visible. Use them where the purpose is obvious from context, and nowhere else.

How to audit a form

Open the checkout, the account creation form, and the contact form, and check every field for a visible label, a programmatic association, and a contrast ratio that passes. Click each label and confirm focus moves to its field. Then fill the form, tab away, and look back: can you still tell which field is which. If the answer is no, the placeholders are doing the labeling, and the form needs real labels before it needs anything else.

Frequently asked questions

Can a placeholder act as the label?

No. Placeholder text disappears when the user types, has poor contrast by default, and is not programmatically associated with the field. WCAG requires a real label element or an aria-label.

Is the floating label pattern accessible?

Yes, when the floated text is a real label element. The text must survive as a label once the field is filled, not vanish like a placeholder.

Do I need a visible label if I use aria-label?

For assistive technology, aria-label is enough. For sighted users, a visible label is still needed, because they cannot see the aria-label. Use aria-label only where the purpose is obvious from context.

What about the search box with just a magnifier icon?

An icon-only search box can use aria-label, because the magnifier is a widely understood convention. A checkout field with no visible label is a different case entirely.