CTUS-79-Error Messaging Best Practices

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

References:

• AODA Compliance: Form Validation

Options considered

Action items

Outcome