Skip to content
UX Atlas
Plate PAT·007 · PatternGrid E2 · Rev. 2026-09-14

Input Validation

Checking input at the right moment, which is rarely while the user is still typing.

PatternExpert heuristicFoundational

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 plate
  1. 1Definition
  2. 2When to validate
  3. 3Requirements for an accessible validation experience
  4. 4Timing by field type
  5. 5Messages that fix the problem
  6. 6One field, three moments
  7. 7In practice
  8. 8Local chart
  9. 9Sources
  10. 10Continue from here

Reach for this when

  • Designing any form.
  • Reviewing form abandonment.
  • A form is rejecting submissions and nobody can say at which field people give up.

Common mistakes

  • Validating before the user has finished.
  • Errors far from their cause.
  • Over-strict format rules.
  • Data lost on failure.

When to validate

TimingUse forAvoid for
On input, as they typePositive confirmation, password strength, character countersNegative judgements before the field is finished.
On blurFormat checks, most field validationFields the user has not yet visited.
On submitCross-field rules, server-side checksAnything that could have been caught earlier.
After first failureRe-validating on input so the error clears as it is fixedThe 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.

Timing by field type

The timing table above is the general rule. This is how it lands on the fields that come up in almost every product.

FieldValidateWhy
Email, phone, postcodeOn blurFormat is only knowable once they have finished
Password being createdAs they type, positivelyThe rules are a checklist they are working through
Username availabilityOn blur, then confirmIt needs a request, and mid-typing is noise
Numeric rangeOn blur, and again on submitPartial numbers are not errors
Required, left emptyOn submit onlyAn untouched field is not a mistake yet
Anything the server decidesOn submitThe client cannot know, so do not pretend

Messages that fix the problem

Do

  • Say what is wrong and what to do: Enter an expiry date in the future, not Invalid date.
  • Accept what people type and normalise it: spaces in card numbers, brackets in phone numbers, any reasonable date order you can disambiguate.
  • Show the rule before the field is filled, where the rule is not obvious.
  • Keep the message beside the field, and keep it there until the field is corrected.

Do not

  • Reject a format you could have parsed. Postel's law is doing real work in forms.
  • Use colour alone to mark a failing field.
  • Wipe the field, or the whole form, on failure.
  • Validate a field the reader has not visited yet, which is telling them off for not having got there.

One field, three moments

still typingtoo earlypositive hints only:strength, character counton blurformat and requiredthe first judgementon submitcross-field and serverplus an error summaryAfter the first failure, re-validate on input so the error clears as it is fixed.
The only judgement that belongs while someone is still typing is a positive one. Everything critical waits for blur, and what the client cannot know waits for submit.

In practice

  1. i.

    Error summary with focus movement

    Long forms

    The 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.

  2. ii.

    Invalid at the first character

    Premature validation

    An email field marked invalid after the first letter is telling the reader they are wrong for having started. Validation before the reader has finished is an interruption, not help.

Local chart

PAT·007 · Region III · Grid E2

This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.

Error PreventionHEUR·005 · PRINCIPLES BEHIND THISHelp Users Recognise, Diagnose and Recover From ErrorsHEUR·009 · PRINCIPLES BEHIND THISPostel's LawLAW·012 · PRINCIPLES BEHIND THISConstraintsPRIN·009 · PRINCIPLES BEHIND THISError Identification and SuggestionA11Y·016 · DEPENDS ONFocus ManagementA11Y·004 · DEPENDS ONLabels and InstructionsA11Y·017 · DEPENDS ONError MessagesWRT·002 · DEPENDS ONDate PickerCMP·009 · OFTEN USED WITHStepperCMP·029 · OFTEN USED WITHText InputCMP·003 · OFTEN USED WITHAuthenticationPAT·023 · OFTEN USED WITH

Sources

Where a source establishes something narrower than the popular reading of it, the note says so.

  1. [1]

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

A CheckoutA FormAuthentication

Principles behind this

The reasoning this solution is an application of.

Depends on

Get these right first, or this one will not hold.

Often used with

These usually appear in the same screen or the same decision.

Practical example

A worked decision where this was the deciding factor.

Check your work

Review passes that test whether this was done properly.

Related concept

Connected closely enough to change how you apply this.