Help users to Correct errors
Use the correct errors pattern when you need to:
- make sure that a user has entered something in an input or field
- check what they have entered is valid
If information is missing or incorrect, advise the user on how to fix it.
Validation should occur after the user submits the form.
When not to use this pattern
Do not use this pattern to tell the user:
- there is a problem with the service
- they do not have permission to do something
Instead, use error or status pages.
How to use this pattern
If the user tries to submit the form with missing or incorrect information:
- display the page again and keep the user’s information in the form fields
- add “Error: ” before the page
<title>for screen readers
- display an error summary at the top of the page that lists all the errors, and move keyboard focus to it
- show the error details next to each field that has missing or incorrect information
There are two types of validation:
- server-side validation
You will always need to carry out server-side validation, even if you use client-side validation. This is because there is no guarantee that client-side validation will work in all circumstances.
Only add client-side validation if you find a user need for it.
For example, because research shows it helps the user if you validate the information they are providing as they type.
Before you add client-side validation, consider that:
- it is hard to tell the user about errors in a way that works reliably across different browsers and assistive technologies
- carrying out both kinds of validation means you have to check their rules do not conflict
Turn off HTML5 validation
HTML5 validation is a type of client-side validation built into browsers. Do not use this as:
- the visual style, placement and content of HTML5 error messages cannot be made consistent with ONS design principles
- ONS error messages are more accessible
To turn off HTML5 validation:
Three components are used in this pattern.
All the errors on a page are listed in an error summary panel.
This must be displayed at the top of the page’s
<main> container and above the
<h1> heading. This ensures it is the first element on the page to be read.
Error summary panel title
To let the user know that there is an error on:
- question pages, use “there is a problem with your answer”
- other pages, use “There is a problem with this page”
If there is more than one error on the page, display the number of errors. For example: “There are 2 problems with your answer”.
Error summary panel body
The panel’s body must contain a list of links for each error.
To do this, use the
onsList macro, set "
"ol". If there is only one error, the macro will wrap the link in a
<p> instead of the ordered list markup.
Each error link must:
- describe the specific error and help the user fix it
- link to the field or fieldset that contains the validation error on the page
- contain a url key value that matches the
idof the panel wrapping the field or fieldset with the error – this needs to start with a hash, for example,
Wrap each field that has missing or incorrect information using an error details panel.
This needs to describe the error and help the user fix it.
The error component is called within each component by providing a
id value within the
The text string for the error details panel must be the same as its corresponding link in the error summary panel.
Guidance on specific error messages can be found on the page for each form component.
The prototype provides an example of form validation for inputs that have missing or incorrect information.
Attempt to submit the form as it is to see the error validation in action.
The form in the example prototype will always fail validation.