Practical guides

Write form errors that help people recover

An error helps only when someone knows what failed and can resume without entering everything again.

Go to the method

Laptop, phone and open notebook on a white table
Illustration

Describe the expected correction

Connect each message to its field and explain the required information. “Email address is incomplete” helps more than a technical code. Do not blame the user for a server outage or unavailable service.

Explain rules before entry where possible: format, length, accepted files and optional information. The contact form guide helps reduce fields and clarify expectations.

  • Field and problem identifiable.
  • Correction action explicit.
  • Constraints explained early.

Make feedback perceivable

After submission, show a summary near the beginning and a message beside each affected field. Move focus predictably and connect each field to its error for assistive technology. Colour alone is insufficient.

The W3C notification tutorial gives examples of local and overall feedback. Test keyboard, screen reader, zoom and narrow screens.

  • Summary and field messages.
  • Accessible error associations.
  • Focus and contrast tested.

Preserve input and intention

Keep valid values after an error, except sensitive data that should not be displayed again. A long form should let someone resume in place. A rejected file needs a format or size explanation.

Distinguish validation errors, network delays and duplicate submission. Repeated clicks should not create multiple requests or orders. Confirmation must say whether the action was actually recorded.

  • Valid fields retained.
  • Network failures handled clearly.
  • Duplicate submissions controlled.

Test real cases

Try empty fields, accented characters, mistyped email, oversized file, expired session and unavailable server. Ask someone unfamiliar with the form to recover without help and observe hesitation.

After correction, check the email or next step, not just the on-screen message. Confirmation and error content also need review in every published language.

  • Representative errors covered.
  • Complete journey checked.
  • Messages translated and reviewed.

Content updated on October 4, 2026

Acceptance matrix to adapt to your project

These proposed checks use synthetic cases. Decide the required behaviour with the team, record the result and assign unresolved gaps before release.

Test cases, expected outcomes and useful evidence
CaseExpected outcomeEvidence to retain
Two fields are invalid after submission.Each error is associated with its field and the summary helps locate them.Record URL, steps, result and dated evidence.

Frequently asked questions

Where should useful form errors appear?

Associate a precise message with its field and provide a summary for multiple errors. Explain correction without internal details. Preserve useful input and check keyboard and assisted reading. Colour alone cannot identify the issue.