...
Success message should be dismissible using an 'X' in the top right corner to close.
...
Success Toast messages
Use toast messages to confirm an action that doesn’t meet the criteria of the Success Alert message above. In general, toast messages should not go over 3 words and should not be used for error messages. Use the ‘noun + verb' pattern for writing toasts such as “Inspection data updated” or ‘File added’.
Do not include an action in a toast unless the same action is available somewhere else on the page.
Make sure toasts appear in the same spot across the entire application and in both portrait and landscape mode. For example, if a toast appears in the top-right corner in portrait mode and the user rotates their device to landscape, the toast should re-orient to the top-right corner.
Toast message accessibility requirements:
Use an ARIA live region using [aria-live=”polite”] so that screen readers announce the toast text after other more pressing announcements
Toast should persist for at least 10,000 milliseconds
For more information on toast message accessibility requirements, refer to the article “Designing Toast Messages for Accessibility”.
Example success toast message:
...
Error summary
Error alerts tell users that the action was unsuccessful or that there was a validation error upon submission of a form. For example, a user incorrectly completes a field and the system does not allow the user to complete the task upon submission unless the errors are fixed. Use a hyperlink for each field that needs to be corrected, listed in the order that they appear on the form. Upon clicking the hyperlink, the user is brought to that field.
...
To help screen reader users, the error message component includes a hidden ‘Error:’ before the error message. These users will hear, for example, “Error: The date your passport was issued must be in the past”.
Be clear and concise
Describe what has happened and tell them how to fix it. The message must be in Enter your first name”.
How to write error messages
Writing good error messages can be difficult. You want to describe what happened and tell the user how to fix it, but make sure you use plain English, use positive language 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’
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 National Insurance number and include ‘QQ 12 34 56 C’ 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
Use the same message next to the field and in the error summary so they:
look, sound and mean the same
make sense out of context
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.
...
be concise.
There is also no ‘one size fits all’ approach for writing error messages and the way you write each message could vary depending on what you are asking the user to do and the type of validation error that occurred.
Whenever you are writing error messages, refer to the GOV.UK Error Message page for detailed explanations of what to do and what not to do, examples, and different use cases. The GOV.UK Recover from Validation Errors page is also a great resource for how to apply validation to your forms and help users recover from validation errors.
Extra technical specifications
A page alert consists of a shaded background with an emphasized left-hand border, an icon, a heading (title of the alert), descriptive text that explains what the alert is about, and in some cases, an 'X' to dismiss the alert (refer to the examples above).
Use FontAwesome-solid icons.
Ensure the colour contrast between the icon colour and the background colour is at least 3:1 (use this WebAIM contrast checker).
When the new page or view is first loaded, ensure that focus is moved to the alert so that screen readers will announce the alert right away.
...