Labels say what to fill in, hints say how

What it is

Field identity and input-specification separation uses a persistent label to name the field's concept and expected value domain, while a hint supplies format, constraint, source, or example needed to complete it. A label answers “what value is this?” and a hint “what makes this value acceptable?” A purpose explanation separately answers “why is it collected?” These layers may cooperate around one field, but placeholder text cannot replace the label: it disappears during entry and can be covered by an existing value.

Why it happens

Someone filling a form must first map a control to a data concept and then produce a value that satisfies its rules. A stable label supports scanning, return editing, error location, and distinction among similar fields; a hint supplies only the additional specification needed for this value. A label reduced to “Enter” lacks identity, while a placeholder serving as both identity and example removes the reference as soon as typing begins. Putting every rule into the label instead harms scanning and error summaries. Programmatic association keeps label, hint, error, and control together through visual reflow, zoom, and linear screen-reader order; position or hover alone cannot preserve that relationship.

Studying it

Build a field × value-domain × state matrix covering empty, filled, autofilled, editing, disabled, conditional, and error-recovery states. Before entry, ask participants to identify field meaning and domain; during entry, ask for format and constraints; after rejection, observe location and repair. Record wrong-field entries, format errors, backtracking, retyping, and recovery time. Compare persistent labels, floating labels, placeholders, and adjacent hints while holding order, hierarchy, and explanatory content constant, including keyboard, zoom, and screen-reader use. Successful autofill does not establish label clarity because the person may never have interpreted the field.

Where it stops holding

When name and domain are hard to separate, a label may include a short qualifier such as “Birth year (YYYY).” The aim is clear information function, not a ban on parentheses. A self-evident field with no special constraint may omit a hint, but it still needs a perceivable, programmatically associated label. A placeholder may carry a supplementary example if nothing depends on its persistence and the example cannot be mistaken for a default. Special controls such as search can sometimes be identified by strong context plus an accessible name, but require separate validation and do not justify hidden labels across a form.

Applying it

• Record concept, value domain, format, constraints, source, and example separately for every field. Use the label for concept and domain, and the hint for specifications needed during entry.
• Keep the label available through empty, typing, autofill, validation failure, and return editing. Use placeholder only as an optional example, never as the sole label, format rule, or recovery instruction.
• Programmatically associate the control with label, hint, required state, and error through platform semantics. Explanation controls must be focusable, touch-operable, and usable with a screen reader; critical guidance cannot depend on hover.
• Regress visual and assistive-technology order with real dynamic values and errors. Users should identify the field, its acceptable value, and how to repair it; information that exists only before typing is a defect.

Related

• Same group: T2.03.2 Give hints before input, not after errors · T2.03.3 Fields of unclear purpose need explanation
• Adjacent: E2.03.3 Labels and inputs must be associated semantically · E2.04.1 Placeholders disappear after input starts and cannot serve as labels
• Search terms: form label · input hint · placeholder versus label