Errors

Consider when errors should be displayed based on the situation, the user, and the current task. Should errors appear when the field loses focus (on blur)? Or only upon submitting information, such as clicking on a "Continue" button?

If the page does reload, consider having an errors summary, including a count of errors, appear at the top of the page; screen readers can then read the error messages sooner on the page. Include anchor links to the specific errors on the page in the summary.

If the page does not reload, then consider bringing the focus to the form field with the first error message and having the screen reader announce the error.

Help the user prevent errors by providing clear field labels and instructions.

• Communicate what has caused the error.
• Describe how the user can fix the error.
• Display the error message at the right time and place.

• Avoid technical jargon. Make sure to use simple words so that the user understands the message’s content.
• Don’t rely just on color. Use supporting text and the error icon.

Tips for Writing Error Messages

1. Error messages should address the user, tell them what happened and instruct them on how to fix it. Example: “There’s already a file with that name. Please try another name.”
2. Always provide a solution for the user when an error occurs. There might be more than one solution to the error, so keep in mind the use case and what makes the most sense for the user when crafting the error message.
3. Speak the same language as the user and avoid technical jargon. Example: Don’t say, “Exception EWiz 545765345 Error code 61”
4. Be concise with the error message.
5. If there is a lot more information to be provided on how to fix the error, provide it in a progressive disclosure. A progressive disclosure is where you hide the remainder error information under a “show more” or “read more” link so that the user can provide more information to support or how to cure the error on their own.
6. Prevent accusatory language so that the user doesn’t feel like they are taking the blame. Example: Don’t say, “You didn’t enter your name.” Instead, say “Please enter your name.”
7. No one likes being yelled at, so be gentle. Avoid using all caps with an exclamation point, and be gentle in your language.
8. Users prefer getting help from a human, so be friendly and avoid sounding like a robot.
9. Avoid directional language, such as “see above.” Content can be scaled and moved around based on screen size so it might not always be accurate.

Displaying errors after page refresh

The following guidelines are for the scenario when the user has submitted form fields and the page refreshes.

1. Use the page title, <title> element of the web page, to indicate errors and number of errors. The screen reader would read this immediately when the page is loaded. Example of page title: “3 Errors - User Information”

   This method can also be used to indicate successes. Example of success scenario for page title: “Thank you for submitting your report”

2. Use the main heading, such as <h1> or <h2> of the web page, to indicate errors and number of errors. The original text of the main heading should still be included. Example of main heading: “3 Errors - User Information”
3. Include an errors summary at the top of the page. The errors summary contains a clear heading and includes a count of the errors. Example: “3 Errors in this form”
4. Display specific, in-line error messages that are physically close to the relevant form fields.