Skip to main content

Prevent and recover from errors

Validation lets me know when I’ve missed something or provided the wrong information in an online form

Validation patterns in forms assist users in skipping or entering information that doesn’t match a specified format. The best applications prevent users from encountering these errors in the first place or provide more permissive entry formats. However, validation is often a necessary stop-gap solution to ensuring that the most accurate information is provided.

There are many scenarios that require different approaches to good validation. The two main considerations for all approaches are;

Prevent users from encountering validation as much as possible. While often necessary, consider form validation something to be avoided. Be as accommodating as possible, whether that means re-evaluating optional questions, loosening the restrictions on responses to questions (doing more parsing in the back end), or providing clear and helpful context to enable users to provide the right information on their first attempt.

Provide a way out to help users recover from errors. Ensure everyone, including sighted, unsighted, low-vision users, or users with cognitive disabilities, can read, understand, and follow instructions to recover from errors raised through validation.

Constraints

The pattern described here works within a few constraints.

Validation happens after the screen is submitted. In an ideal scenario, validation occurs before the screen is submitted. This solution reduces the burden on engineers to maintain JavaScript that would normally support the interactivity required for front-end validation. This recommendation will ensure WCAG 2.1 AA success criteria.

This guidance is mostly agnostic to any design system. But, it is mostly written with the Honeycrisp Design System or the USWDS in mind.

Prevent errors

Illustrate which questions are required. Use the required attribute on required inputs. If a question is optional, consider whether it needs to be asked. If it does, describe it as optional.

Use the appropriate input types and modes that suggest formatting for answers. For example, text for generic alpha-numeric answers, numeric input mode for numbers, email for email addresses, phone for phone numbers, memorable dates, etc.

Provide text to help users understand special formatting. This is text underneath the question label (help text).

Disabled buttons can prevent the applicant from skipping required questions. Ensure you have provided an affordance for sighted and screen-reader users as to why the button is disabled.

Relevant WCAG 2.1 Criteria

View the prevent errors example

Recover from errors

Change the page title so it isn’t the same as the previous page and users know there are errors.

Provide an alert with a summary of validation errors at the top of the page. This should be the very first element, before the skip link, so it is read when the page is opened.

Follow the good message outline.

  1. Say what happened
  2. Provide reassurance
  3. Give them a way out

Provide jump links to each error label or to the first error in the form.

Structure each invalid question so that its validation message is positioned before the invalid input and reads in logical order from top to bottom.

Use the aria-invalid attribute on invalid inputs.

Relevant WCAG 2.1 Criteria

View the recover from errors example

uswds.codeforamerica.org

Learn more about Code for America by visiting codeforamerica.org