Technote

Themes & plugins Practical

Series Accessibility is quality Part 5 of 8

Labels and errors: a placeholder is not a label

Text that vanishes the moment you type cannot be a label. Forms that hide labels and forms that signal errors with colour alone lose people in much the same way.

A form with the labels stripped out and only placeholders left looks tidy. The fields line up, the word count drops, and in a mockup it genuinely reads better. That tidiness only holds while the user has typed nothing.

Three reasons a placeholder cannot be a label

What users lose when a placeholder stands in for a label

That third row runs straight back into the contrast problem from part one. Darken the placeholder and it starts looking like a value already entered, so people skip the field. Used as a label, there is no way out in either direction.

Placeholders themselves are fine. With a real label above and the placeholder showing an example of the expected input, they are genuinely useful. The problem is only ever using one instead of the other.

Labels stay visible, and stay tied to the field

Above the field is the safest position. Long labels wrap naturally, and when someone zooms in on a phone the label and the field stay together.

One more thing is needed: the label and the field must know about each other. Properly paired, clicking the label focuses the field, and a screen reader announces what the field is asking. As a bonus, the tap target grows to include the label, which makes mobile entry easier. It is the common case of an accessibility requirement paying itself back as usability.

If you use a floating label that shrinks into the field, check the size and contrast of the shrunken state separately — that small text is now the real label.

Describe errors in words, not in colour

Turning the field red is not enough. To someone with a colour vision deficiency it can be no change at all, and even when the colour is seen it still does not say what is wrong or why.

An error screen is seen not by a user who failed but by one who almost finished

Error text should say what to do next. “Incorrect format” is a status report; “please use digits only” is a solution. On long forms a summary at the top with links to each field helps — but never replace the per-field messages with the summary.

Required markers follow the same logic. A lone asterisk relies on convention, so either explain it in a line above the form or, when nearly everything is required, mark the optional fields instead.

Our own service request form follows these rules — visible labels, and required fields stated in words. More on forms and screen structure lives in the Themes & plugins archive.

Next part

Next: motion. When someone has asked their system to reduce animation, the question is whether your screen becomes calmer or simply empty.

More on this topic

All technotes

Themes & plugins Practical

Decide the editable regions before you design them

A design the CMS cannot express stays up for negotiation long after it ships. Deciding what editors may change, first, removes the negotiation entirely.

Designers 6 min read

₩270,000 · Join the program