Input Validation
Checking input at the right moment, which is rarely while the user is still typing.
Definition
Validation verifies that input meets requirements. The design decisions are when to validate, where to show the result, and how much to accept before rejecting.
Expert heuristic. A review criterion developed by practitioners. Useful and widely taught, but evaluated by judgement rather than measurement.
On this page
When to validate
| Timing | Use for | Avoid for |
|---|---|---|
| On input, as they type | Positive confirmation, password strength, character counters | Negative judgements before the field is finished. |
| On blur | Format checks, most field validation | Fields the user has not yet visited. |
| On submit | Cross-field rules, server-side checks | Anything that could have been caught earlier. |
| After first failure | Re-validating on input so the error clears as it is fixed | The first pass, which should wait for blur. |
Requirements for an accessible validation experience
- State requirements before the field is filled, not only after failure.
- Show the message adjacent to the field, associated with aria-describedby.
- Mark the field with aria-invalid when it fails.
- Summarise all errors at the top on submit, with links to each field, and move focus to the summary.
- Never clear entered data on a validation error.
- Accept broadly and normalise, rather than rejecting formats a reasonable person would type.
In practice
Error summary with focus movement
Long formsThe pattern used in government service design: a summary at the top listing every problem, each linking to its field, with focus moved to the summary on submit. It works for keyboard and screen reader users and for everyone else.
Sources
Where a source establishes something narrower than the popular reading of it, the note says so.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Applies when you are designing
Principles behind this
The reasoning this solution is an application of.
- Error PreventionHeuristic
- Help Users Recognise, Diagnose and Recover From ErrorsHeuristic
- Postel's LawLaw
- ConstraintsPrinciple
Depends on
Get these right first, or this one will not hold.
- Error Identification and SuggestionAccessibility
- Focus ManagementAccessibility
- Labels and InstructionsAccessibility
- Error MessagesUX writing
Detecting the problem is half the job. The sentence is the other half.
Often used with
These usually appear in the same screen or the same decision.
- Date PickerComponent
- StepperComponent
- Text InputComponent
- AuthenticationPattern
- Autocomplete and TypeaheadPattern
- Multi-Step FlowsPattern
- Payments and CheckoutPattern
Practical example
A worked decision where this was the deciding factor.
- One Long Form or Several Short StepsCase study
Related concept
Connected closely enough to change how you apply this.
- Form Labels and Help TextUX writing