Placeholder text as a label: what breaks and what to do instead

What it is

The placeholder attribute exists to hold what the HTML Living Standard calls “a short hint (a word or short phrase) intended to aid the user with data entry when the control has no value. A hint could be a sample value or a brief description of the expected format.” The same section adds: “The placeholder attribute should not be used as an alternative to a label.”

The pattern in question ignores that sentence. Instead of a label reading “Email address” above a box with a placeholder reading “[email protected]”, the label is removed entirely and the box says “Email address” inside it. The form looks calmer, the layout gets shorter, and every field is self-describing — right up until someone types in it, at which point the description is overwritten by the thing it was describing.

The specification’s own framing is the clearest way to see the mistake. It distinguishes three mechanisms: “the hint given by the control’s label is shown at all times; the short hint given in the placeholder attribute is shown before the user enters a value; and the hint in the title attribute is shown when the user requests further help.” Only one of those is shown at all times, and a label is the one thing in a form that has to be.

The game level named after this, The Placeholder Phantom, pushes the idea past its logical end. The registration form does have labels, but each field carries a fake placeholder — an overlaid element reading “John Smith”, “[email protected]”, “Enter password” — which never goes away. Typed characters and phantom text occupy the same pixels, so the player cannot read their own input; selecting the whole field is about the one way left to see what is actually there. Fields also clear themselves at intervals, which is the level’s way of making a mundane point loudly: if you cannot see the current value, you cannot tell whether the form still holds it.

Why it works on people

The pattern spreads because the mock-up is generally empty. In a design file every field is in its pristine state, showing its placeholder, and the screen looks beautifully uncluttered. Nobody draws the filled state, so the failure mode is invisible at the point the decision is made.

It also appeals to a real constraint. Labels take vertical space, and on a narrow screen a long form with labels is a long scroll. Collapsing label into field is the cheapest way to halve the height. The cost is deferred to the moment of review, which is exactly the moment that matters.

Under the hood, the accessibility failure is subtler than “screen readers ignore placeholders”. HTML Accessibility API Mappings defines the accessible name computation for a text input as an ordered fallback: aria-labelledby, then aria-label, then the associated label element’s content, then the title attribute, then the placeholder attribute, then aria-placeholder. So a placeholder-only field usually does get announced with a name. The problem is that the name is coming from the bottom of that list — a fallback whose exposure has historically varied between browsers and assistive technologies, and which no longer has any visible counterpart on screen once the field has a value.

That mismatch is what makes it hard for a sighted screen reader user, a voice-control user, or anyone working with a magnifier. Speech-recognition users address controls by their visible text; if the visible text is gone, there is nothing to say. Someone magnified to 400% sees a fragment of a row of identical boxes with no headings between them. And Nielsen Norman Group’s review of the pattern lists the plainest cost of all: with no persistent label, users cannot check their answers before submitting, and cannot see what a field wanted when a validation error sends them back to it — they have to delete their entry to make the instruction reappear.

There is a colour problem underneath the structural one. Browsers render placeholder text in a light grey by default, and the W3C’s own forms tutorial notes that browsers usually display placeholder text in a colour that does not meet WCAG’s minimum contrast requirement. Darkening it to pass 1.4.3 makes it look like a real, already-entered value — which is a different failure, and one people act on by skipping the field.

Where you meet it

• Checkout forms where “Card number”, “MM/YY” and “CVC” live only inside their boxes, so a mistyped digit has to be verified against a field with no title.
• Search-and-filter panels where a row of five identical inputs is distinguished purely by grey text that vanishes on first keystroke.
• Sign-up forms where a browser autofills name, email and phone at once and every hint disappears simultaneously, leaving the user to infer which value went where.
• Address forms translated into a language with longer words, where the placeholder is clipped mid-phrase because the box was sized to the English string.
• Floating-label implementations that shrink the label to eight or nine pixels of low-contrast grey on focus, technically keeping it but making it unreadable for the people who most need it.
• Error states that replace the placeholder with the error message, so recovering from the error costs you the instruction you needed to recover.
• “Optional” or format information encoded only in the placeholder, so it is unavailable at exactly the moment the user is deciding whether to fill the field.

Designing around it

• Give every input a persistent visible label element whose for attribute matches the input’s id. That single association is what satisfies the programmatic-relationship requirement of WCAG 2.2 SC 1.3.1, gives voice-control users something to say, and expands the click target to include the label text. Wrapping the input inside the label element works too, but the explicit for/id pairing survives refactors better.
• Keep the placeholder for what the spec describes — a sample value or a note about the expected format — and never put anything in it that the user still needs after they start typing. “Email address” is a label. “[email protected]” is a placeholder. If you can only have one of them, keep the label.
• Put format rules, constraints and optionality in their own element and connect it with aria-describedby on the input. A screen reader reads the described-by text after the field’s name, so “Phone number, edit text, include the country code” arrives as one coherent unit. This also keeps the hint on screen while the field is being filled, which is when it is needed.
• Mark optionality on the label rather than in grey text inside the box, and mark the smaller set — if most fields are required, label the optional ones, and vice versa. Never rely on an asterisk alone without stating what it means.
• Add autocomplete tokens: autocomplete="name", "email", "tel", "street-address", "postal-code", "cc-number" and the rest of the defined list. WCAG 2.2 SC 1.3.5 (Identify Input Purpose, Level AA) is satisfied by exactly this, and the practical payoff is that browsers and password managers fill the right field instead of guessing from the placeholder.
• If you want floating labels, budget the space for them honestly. The label has to remain visible after entry, keep a 4.5:1 contrast ratio against the field background at whatever size it shrinks to, stay legible at 200% zoom and at 400% with reflow, and not collide with the value in a language whose words are longer. If any of those fail, a plain label above the field costs one line and no risk.
• Never draw a placeholder as an overlaid element that persists behind the value. If a design requires text inside the box, use the real placeholder attribute so the browser hides it on input; a positioned span or a background image will sit under the user’s typing and cannot be dismissed by any assistive technology.
• Check contrast on the placeholder itself if it carries any information at all, using the ::placeholder pseudo-element rather than accepting the browser default. If the resulting colour is dark enough to read comfortably, test whether people now mistake it for a filled-in value; if they do, the content belongs outside the box.
• Test the filled state, not the empty one. Type a value into every field, take a screenshot, and see whether you can still tell what the form is asking. Then tab through with a screen reader and confirm each field announces a name that matches its visible text, submit with a deliberate error, and check that the instruction for the failing field is still on screen while you fix it.

Questions

Can placeholder text be used instead of a label?

No. The HTML Living Standard says the placeholder attribute should not be used as an alternative to a label, and the W3C’s forms tutorial says placeholder text is not a replacement for labels. The placeholder disappears when the field has a value, so the person who most needs to know what a field is — someone reviewing or correcting their entry — is the person it stops helping.

Do screen readers read placeholder text?

Usually, but as a fallback rather than as a label. HTML Accessibility API Mappings puts placeholder near the bottom of the accessible name computation, below aria-labelledby, aria-label, the associated label element and the title attribute, so a placeholder-only field commonly is announced. The failure is that support has varied across browsers and assistive technologies, and that nothing remains visible on screen once the field is filled, which breaks review, voice control and magnification.

Which WCAG success criteria does placeholder-as-label put at risk?

Mainly 1.3.1 Info and Relationships (Level A), because the field name is not programmatically associated as a label; 3.3.2 Labels or Instructions (Level A), because the instruction is not present once the field has a value; 2.4.6 Headings and Labels (Level AA), because there is no descriptive visible label; and 1.4.3 Contrast (Minimum) (Level AA), because default placeholder grey usually falls below 4.5:1. Whether a specific implementation formally fails a given criterion depends on the details, but the pattern puts all four in play.

Are floating labels an acceptable alternative?

They can be, if the label really stays visible and readable after entry. Test it at the shrunken size for a 4.5:1 contrast ratio, at 200% zoom, at 400% zoom with reflow, and with a longer translated string. Floating labels also need the vertical space a static label would have used, so they often save less room than they appear to.

Related patterns

• Pre-selected defaults: when the form has already answered for you
• Password composition rules: why “one number, one symbol” backfires
• Signifiers: an affordance nobody can see is not a feature
• Colour vision deficiency: what breaks when colour is the only cue