Skip to main content
Accessibility Field Guide

Error Messages and Recovery

A practical Field Guide page about writing and placing error messages so users can understand what went wrong and recover without guessing.

A person marks a paper document with a red marker.
Photo: A Person Writing on a Document using a Red Marker via Pexels — https://www.pexels.com/photo/a-person-writing-on-a-document-using-a-red-marker-5915234/
View full screen Download image

An error message should help the user recover.

That sounds obvious, but a lot of forms only tell people that something went wrong. They do not explain what happened, where it happened, or what the person can do next.

That turns a form into a dead end.

The user may have entered the wrong format. They may have missed a required field. They may have uploaded the wrong file type. They may have made a choice that changes what the form needs next.

The important part is not just that the page noticed the problem.

The important part is whether the page helps the person fix it.

The common project moment

A team builds a form, search flow, account update, document upload, eligibility questionnaire, payment screen, or request page.

The happy path gets most of the attention. The screen is designed around what happens when the user enters everything correctly.

Then validation gets added later:

  • required fields
  • format rules
  • upload limits
  • date ranges
  • invalid combinations
  • missing selections
  • service or system errors

If those states are not planned, the error experience often becomes whatever the system happens to output.

That is where users get stuck.

The page may say Invalid input.

The field may turn red with no text.

The error may appear at the top while focus stays at the bottom.

The user may have to resubmit the form several times to discover all the problems.

From the team’s side, the form may look complete. From the user’s side, the path just disappeared.

What to notice earlier

The message should name the problem

A useful error message identifies what needs attention.

Less helpful:

  • Error
  • Invalid value
  • This field is wrong
  • Submission failed

More helpful:

  • Enter a date in MM/DD/YYYY format.
  • Select one contact method.
  • Upload a PDF, JPG, or PNG under 10 MB.
  • Enter a 10-digit phone number.
  • The end date must be after the start date.

The user should not have to reverse-engineer the rule from a generic message.

The message should explain how to fix it

It is not enough to say what failed. The page should help the user recover.

A message like Password does not meet requirements may identify the general issue, but it still leaves the user guessing if the requirements are not nearby.

A better pattern is to tell the user what is missing:

  • Use at least 12 characters.
  • Include one number or symbol.
  • Choose a password that does not include your email address.

The same idea applies to forms, uploads, searches, and eligibility flows. If the user can fix the problem, the message should make the next step clear.

The message should appear where the user can find it

Error placement matters.

If the page only shows a message at the top, someone may not know which field needs attention. If the page only shows a message beside the field, someone starting from the top may not know the form has errors below.

For longer forms, a useful pattern is both:

  • an error summary near the top that tells the user the form needs attention
  • field-level messages next to the fields that need to be fixed

The summary helps the user understand the overall problem. The field-level message helps them recover in the right place.

Focus should move in a way that supports recovery

After a failed submission, keyboard and screen reader users need a clear path to the errors.

If the page reloads and focus jumps back to the top without explanation, the user may not know whether anything happened. If focus stays on the submit button while errors appear somewhere else, the user may miss the feedback entirely.

A practical question for teams:

After the user submits the form with errors, where does focus go, and what does the user hear or see next?

The answer depends on the pattern, but it should be intentional.

Common options include moving focus to an error summary, announcing that errors were found, or keeping the user close to the first field that needs attention. The goal is not to create motion for its own sake. The goal is to make the recovery path discoverable.

Do not rely on color alone

A red border can help some users notice that a field needs attention. It cannot be the only signal.

The page should also include text that identifies the error and explains what to do.

This matters for people who do not perceive color differences, people using assistive technology, people under stress, and anyone trying to complete the task quickly.

Color can reinforce the message. It should not carry the message by itself.

Preserve the user’s work when possible

Few things make a form feel more hostile than losing the user’s answers after an error.

If a submission fails, preserve completed fields whenever possible. If something cannot be preserved for security or technical reasons, explain what happened and what the user needs to do next.

Recovery is not only about the wording of the error message. It is also about not making the user redo work unnecessarily.

System errors need plain next steps too

Not every problem is caused by the user.

Sometimes the system is down. A service times out. A file scan fails. A payment processor does not respond. A record cannot be found.

Those messages still need to be useful.

Less helpful:

  • 500 error
  • Unexpected exception
  • An error occurred
  • Unable to complete request

More helpful:

  • We could not submit the form right now. Try again in a few minutes.
  • The file could not be uploaded. Save your work and try again.
  • We could not find a record with that information. Check the number and try again.
  • Payment could not be completed. Your card has not been charged.

A plain next step reduces panic and support calls. It also helps the user understand whether they should retry, correct something, save their work, or contact someone.

Questions teams can ask

During intake or requirements

  • What validation rules does the form need?
  • Which fields are required?
  • What formats, limits, dates, file types, or combinations can fail?
  • What system errors might the user see?
  • What should the user do when each error happens?
  • Are there errors that should be prevented with instructions before submission?

During design

  • Where will field-level error messages appear?
  • Will long forms include an error summary?
  • How will required fields and errors be shown without relying on color alone?
  • What happens visually after the user submits a form with errors?
  • Does the design leave room for longer plain-language messages?

During development

  • Are error messages programmatically connected to the fields they describe?
  • Does the page expose the error state to assistive technology?
  • Does focus move to a useful place after failed submission?
  • Are custom form controls preserving native validation and announcement behavior where possible?
  • Are user-entered values preserved after validation fails?

During QA

  • Submit the form empty. Can you tell what needs to be fixed?
  • Enter the wrong format. Does the message tell you the expected format?
  • Use only the keyboard. Can you find and fix every error?
  • Use browser zoom or a narrow screen. Do messages stay near the fields they explain?
  • Trigger more than one error. Does the page help you move through them?
  • Trigger a system or upload error. Does the message give a useful next step?

Common trail hazards

  • Errors are shown only by red borders or icons.
  • Error messages say Invalid without explaining the rule.
  • The page gives all errors at the top but not near the fields.
  • Field-level errors appear visually but are not connected to the input.
  • Focus stays somewhere unhelpful after failed submission.
  • The user has to submit the form repeatedly to find one error at a time.
  • Instructions appear only after the user has already made the mistake.
  • The form clears completed fields after an error.
  • System errors expose technical language instead of giving a plain next step.

Small habit

Before a form moves to review, intentionally break it.

Leave required fields blank. Use the wrong format. Upload the wrong file type. Pick dates that do not make sense. Trigger more than one error at a time.

Then ask:

If I were using only this page’s feedback, would I know what went wrong, where to go, and how to fix it?

If the answer is no, the error experience needs more work.

Use these as trail markers, not as the whole conversation:

  • Forms and Labels — for making sure the field, label, hint, and required state are understandable before an error happens.
  • Status Messages and Alerts — for deciding whether an error, warning, save confirmation, or loading update needs to be announced.
  • Color-Only Meaning — for error, warning, required, disabled, or success states that rely on red, green, yellow, or gray alone.
  • Focus Visible and Focus Order — for checking where people land after an error summary, failed submission, or recovery step.
  • Form Review Checklist — for a practical form-level review pass.

What to do next