Error Message
Show an error message when there is a validation error. In the error message explain what went wrong and how to fix it.
When to use this component
Show an error message next to the field when there is a validation error.
Use standard messages for different components.
When not to use this component
Don't use error messages to:
- tell a user that they are not eligible or do not have permission to do something
- to tell them about a lack of capacity or other problem the user cannot fix - because the problem is with the service rather than with the information the user has provided
Instead, take the user to a page that explains the problem (for example, telling them why they’re not eligible) and provides useful information about what to do next.
How it works
For each error:
- put the message in red after the question text and hint text
- use a red border to visually connect the message and the question it belongs to
- if the error relates to a specific field within the question, give it a red border and refer to that field in the error message
To help screen reader users, the error message component includes a hidden ‘Error:’ before the error message. These users will hear, for example, “Error: Enter an event name”.
Consideration for bilingual services
All the error messages should be in French, including all hidden text.
<span id="changed-name-error" class="ns-error-message field-validation-error">
<i class="fa fa-exclamation-circle error-indicator errorAlert" aria-hidden="true"></i>
"<span class="ns-visually-hidden">Erreur : </span>Entrez un nom d'événement."
</span>
Be clear and concise
Describe what has happened and tell them how to fix it. The message must be in written in plain language, be possitive, and get to the point.
Do not use:
- technical jargon like ‘form post error’, ‘unspecified error’ and ‘error 0x0000000643’
- words like ‘forbidden’, ‘illegal’, ‘you forgot’ and ‘prohibited’
- ‘please’ because it implies a choice
- ‘sorry’ because it does not help fix the problem
- ‘valid’ and ‘invalid’ because they do not add anything to the message
- humourous, informal language like ‘oops’
- periods at the end of error messages, they are unnecessary
Consideration for bilingual services
In French, error messages should have periods at the end of them.
Do not give an example in the error message if there is an example on the screen. For example, if you are asking for a Social Insurance number and include ‘123 456 789’ as hint text, do not include an example in the error message.
Above all, aim for clarity.
Read the message out loud to see if it sounds like something you would say.
Be consistent
Write messages so that:
- similar errors use similar language
- they make sense out of context
- they reduce the cognitive effort needed to understand what has happened
Use the question or form label in the error to provide context. For example, ‘Enter how many hours you work a week’ for ‘How many hours do you work a week?’
Be specific
General errors are not helpful to everyone. They do not make sense out of context. Avoid messages like:
- ‘An error occurred’
- ‘Answer the question’
- ‘Select an option’
- ‘Fill in the field’
- ‘This field is required’
Different errors need different messages. For example, text fields may be:
- empty
- too long
- too short
- using characters that are not allowed
- in the wrong format
An error for a specific situation is more helpful. It will tell someone what has happened and how to fix it.
Use instructions and descriptions
Some errors work better as instructions and some work better as descriptions. For example:
- ‘Enter your first name’ is clearer, more direct and natural than ‘First name must have an entry’
- ‘Enter a first name that is 35 characters or fewer’ is wordier, less direct and natural than ‘First name must be 35 characters or fewer’
- ‘Enter a date after 31 August 2017 for when you started the course’ is wordier, less direct and natural than ‘Date you started the course must be after 31 August 2017’
Use both instructions and descriptions, but use them consistently. For example, use an instruction for empty fields like ‘Enter your name’, but a description like ‘Name must be 35 characters or fewer’ for entries that are too long.
Use error message templates
Use template messages for common errors on:
How validation works
Use field validation when there's an identified need to show an error message. Display the message right after the user leaves the field (on-blur). Use a button error if the user hasn't corrected the field errors and clicks next or submit. Button errors should display messages, with links, that match the field errors.
Real-time validation
Don't use real-time error validation. Errors that display while a user types are distracting. Real-time errors disrupt the user's thoughts before they've finished and reviewed the answer. When distracted, users can fail to see they've entered the wrong information (in the correct format) causing more severe kinds of user error.
When user testing shows positive messages help user experience, consider real-time positive validation. Use this validation on fields with complex format requirements. Fields such as password creation and email confirmation are good candidates. Don't use real-time positive validation on every field.
Track errors
Find out how often people see them. This will let you:
- improve content
- A/B test variations
- redesign a journey