When pages are returned with errors, an overall error message that indicates that there is a problem with the form can be useful. Currently, the page reloads with the same heading, no overall error and only in-page errors. As a result, some users may not be aware of the errors until they go through the page content.
For example, in the Create Service flow. When the service name and email address fields are returned with errors, users may not be aware of these errors until the navigate through the inputs a second time.
The same technique used on the Sign in page to communicate when someone has entered an incorrect password could be used here; an error message is displayed in a
with the alert role and a tabindex of -1, and focus is moved to this
when the page is loaded. This immediately announces the error message, but keeps the
out of the keyboard focus order.
For more information on tabindex="-1", see MDN Web Docs tabindex page:
Similarly status message do not have status roles. The status message observed on the Notify site also change the user’s context: they appear on a separate page, and the programmatic page title and main page heading also communicate the success status. These techniques communicate this information to the user and so the lack of a status role does not constitute a failure under 4.1.3 Status Messages. That being said, a role="status" with a tabindex of -1 and shifting of focus to the status message may still pose some benefit (for example by announcing the date and time the message was sent without requiring the user to navigate to the page content, as this information appears in the status). In addition, the status currently appears above the main page heading and when users skip to main content they bypass this message. We recommend testing this scenario with screen reader and braille display users to establish if a status role would provide additional benefit or whether the existing techniques in place are sufficient to provide clarity.
E.g., the following status message that appears when a test email is sent does not have a status role.
List of screens to fix:
[ ] Create service name
[ ] Send test message success
Potential fix
Use the status banner component on test message success.
See if we have more screens that could use it. Probably by searching for the class: banner-default-with-tick. fix those too.
Test different scenarios with Fable
Add an error summary to the service creation flow step 2 (create service name and email)
Remember to create error summary when screens have more than 1 input field
This is an interesting idea and certainly a good practice to follow. I had some ideas on how this might work and tried it out on the create service page. By implementing it, it highlights to me that our form labels still need some work. I had mentioned this during the "what is a service" work but it is more evident here:
Since the labelling isn't concise, it becomes confusing when you try to relate the error message to the field. For example, instead of "Enter the part before ‘@notification.canada.ca’: this cannot be empty" it would be much clearer with concise labels like: "Email address: this cannot be empty"
Description of issue
When pages are returned with errors, an overall error message that indicates that there is a problem with the form can be useful. Currently, the page reloads with the same heading, no overall error and only in-page errors. As a result, some users may not be aware of the errors until they go through the page content.
For example, in the Create Service flow. When the service name and email address fields are returned with errors, users may not be aware of these errors until the navigate through the inputs a second time.
The same technique used on the Sign in page to communicate when someone has entered an incorrect password could be used here; an error message is displayed in a
For more information on tabindex="-1", see MDN Web Docs tabindex page: Similarly status message do not have status roles. The status message observed on the Notify site also change the user’s context: they appear on a separate page, and the programmatic page title and main page heading also communicate the success status. These techniques communicate this information to the user and so the lack of a status role does not constitute a failure under 4.1.3 Status Messages. That being said, a role="status" with a tabindex of -1 and shifting of focus to the status message may still pose some benefit (for example by announcing the date and time the message was sent without requiring the user to navigate to the page content, as this information appears in the status). In addition, the status currently appears above the main page heading and when users skip to main content they bypass this message. We recommend testing this scenario with screen reader and braille display users to establish if a status role would provide additional benefit or whether the existing techniques in place are sufficient to provide clarity.
E.g., the following status message that appears when a test email is sent does not have a status role.
List of screens to fix:
Potential fix
banner-default-with-tick. fix those too.Resources
This is an interesting idea and certainly a good practice to follow. I had some ideas on how this might work and tried it out on the create service page. By implementing it, it highlights to me that our form labels still need some work. I had mentioned this during the "what is a service" work but it is more evident here:
Since the labelling isn't concise, it becomes confusing when you try to relate the error message to the field. For example, instead of "Enter the part before ‘@notification.canada.ca’: this cannot be empty" it would be much clearer with concise labels like: "Email address: this cannot be empty"
Here are the changes I was suggesting for this form in particular during the "what is a service" work:
Current
Recommendation
Yael will QA error messages in Staging when creating an account
Hey team! Please add your planning poker estimate with Zenhub @amazingphilippe @andrewleith
Error summary appears in Staging when form fields are left empty at the top of create account page
En Français, aussi