An error is part of the task
People encounter errors while doing ordinary things: signing up for a class, applying for a job, or booking a community space. An error message should help them finish that task. “Invalid input” does not say which input is wrong or what would make it valid. A useful message answers three questions: What happened? Where did it happen? What can I do next?
Consider a registration form that rejects a phone number. “Phone number must include an area code” is more useful than “Error 17.” If the field is optional, the message should not imply that a number is required. If the form accepts only certain formats, explain the format near the field before submission, then repeat the relevant guidance if someone needs to correct an entry. Clear instructions prevent avoidable errors; clear messages help people recover from the rest.
Use specific, respectful language
Describe the issue without blaming the person. “Enter a date in day/month/year format” gives a next step; “You entered the date incorrectly” emphasizes fault. Name the field when that helps someone locate it, and use the same words as its visible label. If the label says “Email address,” an error about “user ID” will be harder to connect to the right place.
Ask for only the correction the form needs. For a password that is too short, say what minimum length is required rather than displaying the rejected password. For an upload, name the supported file types or size limit if those rules caused the rejection. Avoid vague requests such as “Check your details” when the system can identify a particular problem.
Sometimes the system cannot tell exactly what went wrong. A failed connection, for example, may not be caused by anything the person entered. Say that the submission did not go through, preserve what they typed where possible, and offer a reasonable next step such as trying again. Do not turn uncertainty into an accusation or claim that information was saved unless the product can verify it.
Put the message where people can find it
Place a field-specific error beside the affected field, ideally close enough that the connection is obvious. Use visible text, not color alone, to identify the problem. A red border may be missed by someone who cannot distinguish the color, is using a monochrome display, or simply does not know what the border means.
For forms with several errors, an error summary near the start can list each problem and provide a way to reach its field. The summary helps someone understand the scope of the work, while the nearby messages provide detail at the point of correction. If the form moves focus after submission, make that move predictable: taking someone to the summary can work, but the links and field labels must then make the route forward clear.
Keep the person’s completed entries when a submission fails unless retaining them would create a genuine privacy or security problem. Making someone re-enter an entire form because one field needs correction turns a small error into a substantial barrier, particularly when entering text takes extra time or effort.
Make errors perceivable with assistive technology
A message that appears visually may not be announced to someone using a screen reader. Associate each field-level error with its input so the message can be heard when the person reaches that field. Mark the input as invalid while the error applies, and remove that state when the issue is resolved. These connections should be tested in the working interface, not assumed from how it looks.
If errors appear without a page reload, make sure people are notified without interrupting them unnecessarily. A brief notification can signal that a submission has errors; focus management and an error summary can then help them review the details. Repeated announcements on every keystroke may be distracting, so choose a validation moment that supports correction rather than competing with typing.
Accessibility also includes people who use voice control, magnification, keyboards, or touch. Keep labels visible, ensure summary links and controls work by keyboard, and avoid messages that disappear before someone can read them. Test at different zoom levels so an error does not cover the field or the action needed to continue.
Check the path from error to success
Review errors as a short journey, not as isolated sentences. Try submitting a form with empty required fields, an unsupported upload, and information in the wrong format. For each case, ask whether the message identifies the issue, explains the fix, points to the right control, and lets the person continue without losing unrelated work.
A community workshop sign-up form offers a simple test case. If a session is full, changing a name or email address will not help. The message should say that the chosen session is unavailable and, if the service offers alternatives, show how to choose one. If a field is missing, the message should identify that field instead. Good error handling distinguishes between problems someone can correct and situations where the available options have changed.
Finally, check what happens after correction. Does the error disappear when it no longer applies? Can the person submit successfully? Does a confirmation clearly state that the task is complete? An accessible error message is successful when it helps someone recover and move forward.
