Forms and Input

Forms are the most demanding interaction in most interfaces. They require effort from the user. Good form design minimises that effort — bad form design multiplies it.

Field anatomy

Every input field has the same structural components. The label identifies what is being asked — it belongs above the field, not inside it as placeholder text. The input receives the user’s answer. The helper text provides additional guidance — constraints, format requirements, or examples — that helps users answer correctly on the first attempt. The error message appears when the answer is invalid. Each component has a distinct role; collapsing them (using placeholder text as a label, for example) removes a component without removing its function — and the function is then missing.

Placeholder text is not a label

Placeholder text disappears when the user starts typing. This means any guidance it contains becomes unavailable exactly when the user needs it — when they are actively entering their answer. Placeholder text is appropriate for short format hints (“e.g. +44 7700 900000”) inside a field that already has a persistent label. It is not appropriate as a label replacement.

Reducing cognitive load

Ask only for information you need. Every additional field is a cost the user pays. Group related fields — name, address, contact — so the form has a logical structure rather than an undifferentiated list of inputs. Match field width to the expected input: a postcode field should be narrow; a message field should be tall. These constraints communicate expectations and reduce the chance of incorrect answers.

Single-column layout

Multi-column form layouts create ambiguity about reading order and field grouping. A user scanning a two-column form may not be sure whether to read across or down, which fields belong together, or what the intended sequence is. Single-column layouts have an unambiguous sequence and work reliably on all screen sizes.

Validation timing

When to show errors is as important as what they say. Three strategies exist:

Submit-only validation — errors appear only after the user submits. Low friction while the user is filling in the form; can feel like a punishment when many errors arrive at once on submission.

Blur validation — validate each field when the user leaves it (on blur). Catches errors field-by-field without interrupting while the user is typing. The emerging best practice for most forms.

Eager validation — validate on every keystroke. Appropriate only for fields where real-time feedback is genuinely useful: a password strength meter, a username availability check, or a character count. Applied to general fields it feels intrusive — showing “please enter a valid email” before the user has finished typing their address.

Error recovery matters as much as error detection. After a failed submission, preserve every valid value the user entered. Re-clearing a form that partially failed is a significant source of abandonment.

Progressive disclosure and multi-step forms

When a form requires many fields, revealing them all at once creates a wall that increases abandonment before the first field is filled. Two strategies address this:

Progressive disclosure — show only the fields relevant to the user’s previous answer. A billing address field that appears only if “bill to a different address” is checked is simpler than showing it always. A shipping method dropdown that appears only after a country is selected is less overwhelming than all options visible simultaneously.

Multi-step forms — divide a long form into steps, each addressing one logical group of information (account details, then billing, then confirmation). Steps work best when: each step can be validated independently before proceeding; the total number of steps is communicated upfront; and users can return to previous steps without losing subsequent answers.

A step indicator showing current position (“Step 2 of 4”) is essential for multi-step forms — without it, users have no sense of completion progress and are more likely to abandon mid-way.

Accessible forms

Forms are among the most accessibility-critical interfaces. The visual layout conveys relationships — label above input, error message below — but screen readers need those relationships made explicit in the markup.

Labels must be programmatically associated with their inputs using for/id pairing or aria-labelledby. Visual proximity alone is insufficient: a label that sits above a field is meaningless to a screen reader unless linked. An input with no associated label announces only its type (“text input”) — the user cannot tell what is being asked.

Required fields must be indicated both visually and programmatically. The required attribute (or aria-required="true") causes screen readers to announce the field as required. Relying on a visual asterisk without programmatic support fails screen reader users.

Error messages must be associated with their fields. When validation fails, the error message should be linked via aria-describedby on the input — the screen reader then announces both the field label and the error when the user focuses the field. Error messages injected into the DOM after submission must be announced: either move focus to the first error, or use an ARIA live region to announce the error count.

For the full technical picture see focus management and semantic HTML in the Accessibility hub.