patternsUI/UX reference

When should a form show errors?

Explain constraints up front. Validate at a useful moment, then make recovery obvious.

Recommendation

Start with validation on submission; add earlier checks only when user testing shows they help.

Problem

People keep getting stuck while filling in a form.

Validate before submission when

  • A format error can be corrected before the user invests in the rest of the form.
  • An error is actionable and you can explain exactly how to fix it.

Validation mistakes to avoid

  • Flagging incomplete input as an error while someone is still typing.
  • Relying on browser validation alone for rules that must also be enforced on the server.

Example

Get project updates

Use an address like alex@example.com.

Implementation

  1. Use visible labels, identify required fields, and explain unusual formats before input.
  2. On failed submission, preserve values and describe each error in text with a useful correction.
  3. Use a linked error summary when errors may be missed. Move focus to the summary, or to the first invalid field in a short form.
  4. For custom validation, associate inline errors using aria-describedby and set aria-invalid after detecting an error. Clear each error when its failing rule has been checked again and passes.

Tradeoffs

Earlier feedback can prevent wasted effort, but interruptions can make typing harder. Server checks need pending and failure states; a network failure is not invalid input.

Verification

Can someone find every error, understand the correction, and submit without re-entering valid information?

References

Related patterns