Status Notifications inform users that something on the page has changed. These responses help users understand page processes, actions they have competed, additional options available, or actions still needing attention. Common examples include success and warning messages.
Depending on the information being communicated, status notifications can be persistent or transient. While it’s important to keep users informed when there is an update or status change, these notifications should not be page blocking.
Transient Status Notifications have the following requirements in addition to the requirements for Persistent Status Notifications (TODO should requirements that are pertinent be additive or all inclusive?)
The concise messages contained within Status Notifications are not required for a user to interact with, may open unexpectedly,
and should not be blocking. Note that opening in an overlay may disrupt or confuse users and may not be seen at all by users at some breakpoints.
Not block page content
Return user focus to a logical location
If moving focus to the notification, the notification:
Must provide at least one focusable UI element (i.e. close button, primary button)
Content container must be dismissible
On dismiss, must return focus to the next logical location in the page flow
Meet the standard color ratio requirements for both text (4.5:1) and activatable components (3.0:1)
Be used for short messages to confirm an action
Be located near or on top of navigation area
Contain interactive controls if notification is displayed as an overlay
Open as a blocking overlay window
Appear as a timed display
If opening a Status Notification consider the following:
A blocking window can introduce obstruction issues for people who have zoomed in browsers or for users at smaller breakpoints
A non-blocking window may be completely missed by those who are using screen magnification software, but who are not using a screen reader
In some scenarios status notifications may be displayed for a set amount of time rather than become a lasting feature of a page. In these cases there should be no negative impact on their current activities or the status that the message conveyed. Ignoring a timed notification would still mean that the action is completed successfully.
For example, an item would still be added to a cart regardless of a user's engagement with the notification informing them of the successfully added item.
Interactive controls within notifications produce several hurdles for users of assistive technology.
Specifically, the Aria-live region will not preserve the semantics of elements being read aloud.
As an example, consider the virtual outfitting notification previously seen on the product page: a user will not know what the title, copy, or link are in the following text:
"Need help deciding? Schedule a free 1-on-1 virtual appointment with one of our experts. Book now".
Users may infer the "book now" text is a link - or just as likely search for a button or guess the entire text would be active.
Consider the following:
When triggered, live regions only read out their content to assisted technologies. They will not distinguish text from actionable elements present within a notification
Users may infer that actionable element is present, however a user will need to guess what element to search for. This is especially problematic for notifications that are automatically dismissed, as users will have limited time to correctly guess and act on this choice
If the notification must include an actionable element, you are responsible for the following:
Return focus to next logical location in the page flow
Contained action is also readily available on the page
If the action is not available on page, the action should be added to a notification history page (see ARIA’s log role)