Help users to Recover from validation errors

Check the information the user gives you to make sure it’s valid. If there’s a validation error, tell the user what’s gone wrong and how to fix it. Turn off HTML5 validation.

When to use this pattern

Use validation to identify when the user tried to provide infomation that you’re not able to use. So you can show the user an error message that helps them to fix the problem.

But minimise your chances of needing to show an error message in the first place by:

• making sure your questions are well designed
• accepting information in different formats, as long as it’s not ambiguous (for example, you should accept postcodes with or without spaces - and names that include non-alphabetical characters or diacritics (for example, an apostrophe or accent)

When not to use this pattern

Do not use validation to check whether the user is eligible to use the service or has permission to do something. Instead, take them to a page which tells them they’re not eligible and gives them useful information about what to do next.

There are separate patterns for:

• ‘there is a problem with the service’ pages
• ‘page not found’ pages
• ‘service unavailable’ pages

How it works

Validation should refuse to accept:

• information that can’t be correct
• information that’s too ambiguous for you to use
• missing information, if the information is required

For example, if you’re asking for someone’s date of birth you shouldn’t accept ‘13’ in the month field.

How to tell the user about validation errors

If the user’s answers fail validation:

• show them the page again, with the form fields as the user filled them in
• add ‘Error: ’ to the beginning of the page <title> so screen readers read it out as soon as possible
• show an error summary at the top of the page, and move keyboard focus to it
• show error messages next to fields with errors

Read guidance on writing good error messages.

When to tell the user about validation errors

Do not validate when the user moves away from a field. Wait until they try to move to the next part of the service - usually by clicking the ‘continue’ or ‘submit’ button at the bottom of the page.

Generally speaking, avoid validating the information in a field before the user has finished entering it. This sort of validation can cause problems - especially for users who type more slowly.

Only add this sort of validation if your user research shows that, on balance, it solves more problems for users than it causes. For example, the character count component shows users an error message when they go over the character limit. Because it’s important that users do not spend time and effort writing out a response that turns out to be too long.

If you do use this sort of validation, make sure you do it in a way that’s accessible.

Client side and server side validation

There are 2 ways to carry out validation:

• server side validation
• client side validation (in the browser, using either JavaScript or HTML)

You’ll always need to carry out server side validation, because there’s no guarantee that client side validation will work in all circumstances. For example users can bypass client side validation, or JavaScript can fail to load.

Avoid adding client side validation unless you can establish that there’s a need for it. For example, because user research shows it’s helpful to users if you validate the information they’re providing as they type.

If you do use client side validation, make sure your client side and server side validation rules do not conflict.

Turn off HTML5 validation

HTML5 validation is a type of client side validation built into browsers. Do not use it because:

• the visual style, placement and content of HTML5 error messages can’t be made consistent with the GOV.UK Design System
• we know that the GOV.UK Design System error message and error summary components are accessible

To turn off HTML5 validation, add ‘novalidate’ to your form tags.

Do not add ‘required’ to your input fields.

Research on this pattern

This approach to validation has been used on a number of services over an extended period of time. For example, Renew or replace your adult passport.

But we’d like to expand the guidance, and we’re especially interested in hearing from teams whose research has identified a need to use client side validation.

We’d also like to know about any research into whether not adding ‘required‘ to form fields causes problems for screen reader users.

Help improve this page

If you spot a problem with this guidance you can propose a change.

If you're not sure how to do this, read guidance on how to propose changes in GitHub.

Need help?

If you’ve got a question about the GOV.UK Design System, contact the team.