In a design system's text field spec, what do the label, helper text and error message each do, and why can't placeholder text replace them?
answer
- four text parts, four jobs
- which part survives typing
- hint before, error after
- faint, vanishing, looks pre-filled
- last-resort fallback name
basics
~20 sThe label names the value and stays visible; helper text gives purpose or format; the error message says what is wrong and how to fix it. Placeholder text vanishes on typing, is often too faint, and makes a poor name.
solid answer
~50 sA text field is a small stack of parts. The **label** names the value the field wants and stays visible before, during and after typing; it is also what voice-control and screen-reader users know the field by. **Helper text** carries purpose, format or constraints, such as 'the 8-digit number on your wristband', and stays up while the person types. The **error message** appears only when a rule fails and says, in words, what is wrong and how to fix it. Placeholder text can do none of these jobs: it disappears on the first keystroke, so the instruction is gone exactly when it is needed; it is usually styled faint, and faint text often fails the WCAG 2.2 4.5:1 text contrast minimum; it can look like an already-filled value; and assistive technology only uses it as a low-quality fallback name. At most it is an optional example.
go deeper
Name the three core text parts of a field and the one job of each, then give two concrete reasons placeholder text cannot stand in for the label.
Explain which WCAG 2.2 criteria bite here, 1.4.3 contrast on placeholder text, 3.3.2 labels or instructions and 2.5.3 label in name, and how the helper and error slots share space.
Show how you would audit an existing library that ships placeholder-only fields: find the instances, decide on floating versus top labels, and migrate without breaking every product's layout.
Frame the anatomy as a cross-platform contract the system owns, so web, native and design-editor components map the same parts by job rather than copying one platform's widget.
## What a text field is made of A **text field** is the component that takes free typed input: a name, a date of birth, a medical record number, a short answer. Most design systems specify it not as a box but as a small stack of parts, each with one job. Getting the anatomy right matters more than any styling decision, because each part serves a different moment in the person's task. | Part | Job | When it is visible | Who depends on it most | |---|---|---|---| | **Label** | Names the value the field expects | Always: before, during and after typing | Everyone; voice-control and screen-reader users use it as the field's name | | **Helper text** | Explains purpose, format or constraints | Before input, and while the person types | Anyone unsure what counts as valid | | **Error message** | Says what is wrong and how to fix it | Only when a value fails a rule | Anyone who made a mistake and cannot see why | | **Placeholder text** | An optional example inside the empty box | Only while the box is empty | Nobody critically | Optional parts sit around the same stack: a **required or optional marker**, a **prefix or suffix** for units such as 'kg' or 'mmol/L', a **character counter**, and a **clear action**. Each of those is added per use; the label, helper slot and error slot are the core. ## Why placeholder text cannot do those jobs The temptation is space: a label inside the box saves a line. The costs land on the people least able to absorb them. - **It disappears on the first keystroke.** A patient typing an insurance number who wonders halfway through whether it was the member ID or the group ID has nothing left to check. The instruction now lives in short-term memory. - **It is usually styled faint.** Designers lighten it so it does not look like a value. WCAG 2.2 success criterion 1.4.3 Contrast (Minimum), level AA, applies to placeholder text too, so faint grey often fails the **4.5:1** minimum; darken it enough to pass and it starts to look like a filled-in value. - **It can look like an answer.** A box showing a date format in grey reads as already done to some people, who skip it and meet an error. - **It is a poor name.** The accessibility naming guidance treats placeholder text as a last-resort fallback that yields a low-quality accessible name. A field whose only name is a vanishing hint has no dependable name. - **It hides meaning on review.** Once filled, a form of placeholder-labelled fields is a column of values with no captions; a person checking before submission cannot tell which box is which. ## What the spec should write down 1. Every text field has a **visible, persistent label** outside the typing area (or a floating label that moves but never disappears). 2. Helper text sits in a fixed slot, usually below the box, and **stays visible when the field has a value**. 3. The error message uses the same slot or one directly beside it, in text, with a non-colour cue. 4. Placeholder text is optional, holds only an example, and is **never the only place a rule lives**. 5. The label, helper and error are tied programmatically to the field, so a screen reader reads them on focus; how that is spelled is the platform's business. Two WCAG 2.2 criteria anchor this: **3.3.2 Labels or Instructions** (level A) requires labels or instructions when content needs input, and **2.5.3 Label in Name** (level A) requires the field's accessible name to contain the visible label text, so a person saying 'click date of birth' reaches the right field. ## The same anatomy on every platform Native mobile platforms and the web draw text fields differently, and a design editor's component mirrors whichever the team designs first, but the anatomy is shared: every platform has a way to give a field a persistent name, an attached description and an error state. A system that specifies the parts by job rather than by one platform's widget lets each team map them to its own controls without renegotiating the rules. ## A patient-portal example For a field asking for a medical record number: - **Label:** 'Medical record number'. - **Helper text:** 'Printed on your wristband or discharge letter. 8 digits.' - **Error:** 'Enter the 8-digit number from your wristband or discharge letter.' - **Placeholder:** none; the helper already carries the example. The label answers 'what is this', the helper answers 'where do I find it', and the error answers 'what do I do now'. None of those answers can be allowed to disappear while the patient is typing.
- Is a floating label, one that sits inside the empty box and shrinks above it on focus, an acceptable substitute for a label above the field?It can be, because the label moves rather than disappears. The risks are in execution: the shrunken label is often too small or faint to meet contrast, the empty field can look pre-filled, the motion can distract, and there is no room left for an example. If the system ships one, test the shrunken state against the same contrast and size rules as any label.
- When is a visually hidden label acceptable for a text field?When the surrounding interface makes the purpose unmistakable to sighted users, such as a lone search field beside a button reading 'Search'. The field still needs an accessible name that matches what is shown nearby. For anything people answer from memory, like a date of birth or a policy number, a visible label is the safer default.
- Should the helper text disappear when an error message appears?Systems differ. Replacing the helper with the error keeps the field's height stable but removes the hint exactly when the person needs it; showing both keeps the hint but makes the field taller. A common compromise is to write the error so it restates the needed format, so nothing the helper said is lost.
A placeholder used as a label is like instructions printed on the flap of an envelope you tear off to open it: they vanish at the exact moment you need them. A label is the address printed on the front.
saying these in an interview costs you the question
- Placeholder text is a fine label because it saves a line of space.
- Helper text only matters for screen-reader users, so it can be hidden visually.
- The accessible name can be any text; it need not match the visible label.
- Helper text should disappear once the field has a value.
- If the placeholder shows an example, no other instructions are needed.