Errors can be scary and confusing. By using some of these best practices, designers can help the user understand the error and how to fix it. If an error must be shown, the user should be able to immediately understand what mistakes they've made or which system errors have been triggered; and they should get clear guidance on how to resolve the issues.

Overall, the user needs to be guided towards the smoothest journey possible. Errors should be helpful, and never blame the user. Use the following guidelines to find the most appropriate error format and messaging to help the user understand and/or correct the issue.

Best Practices Validations Disabled Buttons

Best Practices

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.


Validations should be in-line so that as soon as the user has finished completing a field, an indicator appears nearby if the field contains an error. Minimize form text to the essentials. Not every text field needs helper and/or error text.

Use when:

You need to check the validity of an input and provide feedback before submission.

What to use:

Text Field, Required Fields, Banners (if applicable)

Content Guidelines:

  • Avoid using the word “invalid” to define an error. When appropriate, use “not valid” instead.
  • Highlight all areas that need to be fixed with clear messaging on why the error occurred.

Validations Best Practices

  • Display the error message after the user has interacted with the input.
  • Highlight the input red and display a clear message below indicating why the error appeared.
  • Display an error for each input if there are multiple. For forms, also add an error summary message when the user tries to submit.
  • Place instructions for filling out the form above the field.
  • Be polite in language and clearly inform the user how to fix the error.
  • Don’t display the error message before the user has moved away from the input.
  • Don’t rely just on color. Use supporting text and the error icon.
  • Don’t disable the primary action button. Use supporting messaging to indicate why the form cannot be submitted.
  • Avoid directional language such as “the button on the right.”

In-line Errors

Incomplete forms:

Empty required form fields should be indicated by both the text field and error message below. Using an asterisk (*) along with instructions that certain fields are required, can help alleviate the amount of incomplete form errors.

Display incomplete form errors to indicate a user has skipped a field after they have advanced through a form. If unable to detect user progress through the form, display an error after the user has attempted to submit the form.

Example of an incomplete form.

Multiple errors before form submission:

Display error messages next to each field as the user works through the form. Each form field should still keep the same rules and error structure. Additionally, add an in-line error banner to explain to the user that there are multiple errors that need to be addressed.

Multiple validation errors

Example of using a banner for multiple errors.

Form submission:

Enable the submit button at all times; even when the form is blank. Especially in longer forms, the user may not be aware of what to do in order to be able to submit the form. Once the user clicks the button, show the error summary indicating why the form can’t be submitted (missing required fields or fields that aren't in a valid format).

Reload the form with consolidated error messages and scrollto the top. Error messages for individual fields may be resolved as the user works through the form.

Form Submission Error Validation

Example of an enabled button with an error message.


  1. Form Field Label: The form field label is important because it tells the user what content goes in the form field itself. Make sure this is clear and concise.
  2. Error Icon: Place the error icon after the form field label. This gives the user a visual so that they don’t have to rely just on color.
  3. Form Field: Change the color of the input border to red so that the user doesn’t have to just rely on the error help text.
  4. Error Help Text: Tell the user how to fix the error in the form field. Be specific, concise, and use the same language as the form field label.

Disabled Buttons

When an element in the user interface is disabled, it’s an indicator that something is wrong. Disabled buttons do not explain what's wrong to the user, cause confusion, and possibly lead to abandonment of the application workflow. Additionally, disabled buttons hide the call to action within the workflow.

Disabled buttons are not focusable for keyboard interactions, making them inaccessible. They also usually have insufficient contrast, which contributes to inaccessibility.

Whenever dealing with disabled buttons, ask yourself if there is a better way to communicate the options that the user has. Think about the ways to connect with the users despite the errors — with a default selection, tooltips and hints, as well as actionable calls to action. Use disabled buttons sparingly and with purpose (but really, try not to use them at all!).

Use when:

Don’t use if at all possible. Think of a different solution that does not involve disabling a button.

What to use:


Content Guidelines:

  • If a button needs to be disabled, place the error message in context to where the error has occurred, explaining why the button is disabled.
  • Tell the user within the field instead of disabling the call to action.

Disabled Buttons Best Practices

  • Allow the user to select submit buttons, even if content is missing or incorrect and prompt the error messages. This is a clear way to communicate the issues to the user.
  • Disabled buttons must be focusable and be paired with a message explaining why the button is disabled.
  • Don’t hide the error message behind a tooltip.
  • Don’t use disabled buttons if the form is still empty.

What not to do with disabled buttons

Example of how not to use a disabled button.

Example of how to show an error with an enabled button.

Back to Top