Add your comments directly to the page. Include links to any relevant research, data, or feedback.
Background
As part of our guidance on “writing for the web”, we should include best practice on developing error messages. This will provide consistency across applications, as well as improving accessibility and user experience.
This section is for best practice on writing messages. Implementation of messages should be included under Common Style - Forms.
Relevant data
This page describes the best practices for writing messages, in order to create a consistent approach on our applications. It does not describe how to implement the error messages - this will be found at X.
Definitions
field level validation -> when we're checking to see if the field is blank or conforms to a particular format. e.g. did you enter the phone number in the correct format including area code
form level validation-> when we're validating if what the user has entered allows them to go to the next step in the process. e.g. is the area code 416 or 647? if it is then continue or if it isn't exit the application
Guidance
Keep language simple. Avoid extra words like “please” and “sorry”.
Where is the error? Use the field label name to avoid ambiguity.
What is the error? Is the format invalid, are there illegal characters, etc.
How do I fix it? Be specific. Instead of just saying “the format is invalid”, tell the user what the valid format is.
Sample messages for common errors
Error example | Message text |
|---|---|
Mandatory field | <field> is required and cannot be left blank. |
Invalid postal code | Postal code must be in the format of M1M 1M1. |
Invalid phone number | The phone number must in the format of ###-###-####. |
Invalid email address | The value is not a valid email address. |
Email addresses do not match | The email addresses must match. |
References:
AODA Compliance: Form Validation
Options considered
Option 1: | Option 2: | |
|---|---|---|
Description | ||
Pros and cons |
|
|
Estimated cost | LARGE | MEDIUM |
