Notifications provide important, contextual information that may or may not not require the user to take action.
Page-level notifications should appear below the page title and above the content.
Section-level notifications should appear below the section header and above that section's content.
Alerts and errors are displayed with the following priority:
Alerts and errors may include an optional title.
Minor modifications can be made to the paragraph styling for an alert or error, but its heading styling should not be changed. Use screenreader-only text because notifications should be readable without a style sheet.
Navigation should be precise to each identified error and without the necessity to navigate the entire form. Notifications may include an optional list of one or more anchor links if the alert is specific to features farther down the page.
In cases with limited space, an appropriate icon (success, informational or error) can be used to trigger a tooltip that houses the notification message.
Alerts and errors do not include marketing or promotional content.
Alerts and errors do not use interstitial or modal transitions that leverage static content.
Sufficient details should be provided for the user to address any user error. Error message text should be associated with each feature in error so that all errors are understandable and potentially correctable.
Consider next steps. When the user is required to do something in response to notification, let them know what they need to do and make that task as easy as possible. Think about how much context to provide with your message.
Write the message in concise, human readable language; avoid jargon and computer code.
Be polite in error messages — don’t blame the user.
Notifications are an opportunity to educate users because users will read a message that helps them resolve an error even if they won’t read documentation.
Don’t overdo it. Too many notifications will either overwhelm or annoy the user and are likely to be ignored.
Understand the user’s context. Don’t include notifications that aren’t related to the user’s current goal.
Alerts include success messages and important information that do not require action by the user.
Can be collapsed and reopened.
Errors notify users that something has gone wrong, giving their progress either a temporary or permanent “stop”.
Cannot be collapsed due to their importance.
Catastrophic errors appear by themselves, without the distraction of other error and alert types.
Error notifications are automatically removed, independent of other error messages, when each error state is resolved.
The meaning of an error notification should be conveyed through means other than color alone (i.e. an icon and explicit title).
Labels are the smallest type of notification, used to reinforce content and file types, such as help content, primary subject matter, secondary subject matter, and content related to purchases.
Any of the brand approved colors for containers may also be used for labels so long as the implementation follows usage and accessibility guidelines.
Badges are typically used to highlight the amount of items needing attention, such as items in a cart, unread messages, or alerts that are awaiting action.
No badge is shown if the badge count number is zero.
Badge counts in excess of 999 will display “999+”.
Title case, 2-3 words maximum.
Do not combine actions in a label (exception: "Customize & Buy").
If standard labels don't fit the button's purpose, align label with the task the user is attempting.
Please refer to the Dell Technologies branding website, https://brand.delltechnologies.com/faq/#voice, for further information regarding call-to-action labels and usage.
To be determined.
Alerts and errors are assertive live regions and will be processed as such by assistive technologies. They are specialized forms of the status role.
The alert role goes on the node containing the alert or error message.
Use the proper ARIA role:
Don’t visually hide alert messages and then make them visible when they are needed. Users of older assistive technologies may still be able to perceive the alert messages even if they are not currently applicable.
Alert and error messages should be easy to understand and should state the issue in terms that make sense to the user (as opposed to using technical jargon that makes sense only to a developer).
An error should be associated directly with the page feature that needs to be corrected, and the recovery instructions should be easy to both follow and execute.
Visual and textual cues: The meaning of an error notification should be conveyed through means other than color alone (i.e. an icon and explicit text description).
Use screenreader-only text because notifications should be readable without a style sheet.
Focus and navigation to errors: All errors notifications should receive focus, and navigation to them should be possible by keyboard with a minimum number of keystrokes.
Anchor Links: Navigation should be precise to each identified error and without the necessity to navigate the entire form.
It is not required to set or manage focus to alerts or errors in order for them to be processed. Users are therefore not required to close an alert or error.
If the operating system allows, the user agent should fire a system alert or error event through the accessibility API when the WAI-ARIA notification is created. If the notification requires focus to close or collapse it, then use alertdialog instead.
Alerts and errors have an implicit aria-live value of assertive, and an implicit aria-atomic value of true.