Form validation and error handling

• Overview
• Validation methods
  • Required fields
• Error messaging
  • Identify the fields in error
  • Describe the errors
  • Manage focus
• Resources

Overview

A well-designed form should be easy for everyone to complete. After you've planned, designed, and labeled your form, you need to consider when the form fields will be validated and how errors are indicated, both of which can affect the accessibility of the form. For example, people with low or no vision may have difficulty finding errors that are indicated using only color.

Validation methods

Validation can happen as someone is filling out the form (client-side validation) or after they submit the form (server-side validation). There are pros and cons to both types of validation; a combination of the two will often provide the best experience.

Client-side validation can help identify errors before the form is submitted, but the interruptions from error messages can also be distracting and frustrating. Carefully consider which fields are most in need of client-side validation to find a balance between providing helpful information and interrupting.

Server-side validation, which is important for security, can also make your form more accessible by providing needed feedback on missed required fields or improper formatting. Because of this, don't disable your submit button. Disabled submit buttons can be confusing and prevent someone from taking advantage of that server-side validation.

For more about form validation, see:

• The University of Washington provides an overview for using accessible methods of form validation.
• Mozilla Developers Network (MDN) explain form data validation, including client-side versus server-side validation, and show code examples on how to implement validation techniques in HTML, CSS, and JavaScript.
• The W3C provides a tutorial on validating input, including input formats, client-side validation, and validation by the user.

Required fields

Using the HTML required attribute provides built-in client-side HTML5 validation: if the field is empty, it's invalid. However, following the best practices described in Required attribute requirements includes adding a novalidate attribute to the <form> element, which removes built-in validation. See Label a form for more about labeling required fields.

Error messaging

Form errors need to be clearly indicated for a form to be accessible. There are three critical aspects to this: identifying the fields in error, the description of the errors, and focus management.

Identify the fields in error

To be accessible, each field in error should have a programmatically attached inline error message visually located directly below the field. The aria-describedby attribute is commonly used to associate the error message with the field.

<label for="name">Name (required)</label>
<input type="text" id="name" aria-describedby="error">
<span id="error">Name is required. Please enter your response.</span>

Tip: Consider using aria-live="polite" as an alternative to role="alert". The aria-live property can be used on an element that will update, creating a live region. This is particularly useful for notifications that appear before submitting the form.

If more than one field on the page is in error, provide both inline error messages and a list of the errors at the top of the form, with links to each field in error. A linked list of errors at the top of the page is more accessible than an alert dialog that must be dismissed before the errors can be corrected because the information is available on screen and can be referenced as needed. Be sure to indicate the total number of errors, perhaps as a heading.

Describe the errors

Each error message should clearly describe what the problem is. If possible, also provide suggestions for correcting the error, such as necessary formatting. As a best practice, error messages should be concise and polite.

First name is required.

Please enter your email address in the format: email@example.com.

Date selected must be after today's date.

Manage focus

For a single error, place focus on the field in error so the error can immediately be corrected.

For multiple errors, place focus on the list of errors at the top of the form. This informs everyone of the number of errors and their locations.

Resources

• Level Access discusses how to provide accessible error identification, including validation on form submit, alert box messages, inline error messages, and dynamic form validation, along with visual considerations like focus management and color.
• The Web Accessibility Initiative (WAI) offers a tutorial on how to provide user notification of errors, including examples and descriptions for different methods of providing feedback.
• The BBC GEL design system provides recommendations for markup, layout, and behavior for labels, error messages, and error states.