Notifications: accessibility considerations and general comments on discrete types

[mbgower]

Background

This is an omnibus discussion on Carbon's Notification component. It captures a number of considerations covered in a review (by Jess Lin and me) of Carbon material, more thoroughly documented in a series of commented PDFs (which are definitely worth reviewing):

• Notifications pattern.pdf
• Notification usage.pdf
• Notification style.pdf

Shixie already opened an issue on a number of Notification challenges. Without restating those, I have tried to cross-reference the individual points, where relevant in my discussion below, but a review of Shixie's issue is worthwhile.

Given some of the cross-over between notification and modal, it is worth pointing out that issues and discussions have been created on the Modal component. carbon-design-system/carbon-website#3312 is a good starting point for that work.

In Progress
Note that this document is being added to, and should not be considered to be stable until this 'in progress' information is removed.

---

Themes

I've tried to break down this dicussion into a number of themes.

• Variability
  A primary challenge with the Notifications material in Carbon is how variable the Notification component can be. This may be regarded as a 'feature', but from an accessibility perspective, different combinations result in different implementations, so a clearer distinction can help guide Carbon users (and authors) to a more consistent and accessible experience.

• Interaction differences
  In line with variability, is the fact interaction models can vary, and do not seem to be consistently linked with different variations on notifications. When an interaction changes, we need to make sure it is accessible and predictable (that we follow conventions).

• Lack of differentiation
  Another challenge is how little differentiated the Notification is from the Modal component -- and likewise, how Carbon does not distinguish between a dialog and a modal, but seems to use the terms "synonymously".

• Status
  The continuum of 'importance' in the status conveyed in notifications -- from information to success to warning to error -- suggests there may be an ability to differentiate interaction based on both the need to act and 'to know'. This is a possible area to explore to get to a place of consistency and predictability, which are core accessibility challenges at the moment.

• Interference with other content
  In addition to potential distraction as a result of notifications, there is also a risk of the notification itself obscuring any content over which it appears. When WCAG 2.2 is adopted, any notification that entirely covers (obscures) a control receiving focus will cause a failure of Focus Not Obscured (Minimum).

I'm going to expand on each of these in turn. Since this is a discussion, I'm going to keep things at times a little abstract, sorry!

---

Variability

Notifications are comprised of status and type. Their status signifies the purpose of the information
being conveyed. Notification types allow you to tailor the disruptiveness of the notification to the
specific situation. Notification status and type options in Carbon should be combined

I'm going to suggest that a primary distinction between a notification and a dialog is a that notification requires no user interaction other than, potentially, dismissal. A dialog requires some response or input from the user.

I don't think the 6 patterns types are clearly carried through to the component level.

Differentiation

The pattern divides notifications into 2 broad categories, task-generated and system-generated. The former seem more dialog-like, while the latter seem more notification-like. In both categories, there tends to be a divide between whether or not user response is required, although it's not perfect

No user action

• a form is successfully submitted
• planned system maintenance is coming soon

User action

• there is a problem uploading a file
• credentials can't be found

Possible user action

• a new report is ready
• the user's login session is about to expire
• a user loses network connection

Status

The table on the 4 types of status outlines the user experience in the Action column. This is not a bad model to pursue, but accessibility needs to be brought to bear and the dividing lines between the types probably need to be much clearer.

An obvious consideration is that Carbon largely relies on color to distinguish types. I think it makes sense to always require icons as a redundant visual indicator.

Interaction

The notification panel discussed in the notification pattern does not appear in the notification component. It is a good example of something that could use a better defined, more consistent interaction model -- and which may provide Carbon with a way to address a missing piece in their model -- the non-modal 'dialog'. That is, something that is parallel to the main user task, which the user may wish to switch to, then switch back to the primary task. This is simple with a mouse; less simple with a keyboard. There are also a lot of considerations around 'disruption' of user task to consider.

Walk me and other 'side assistance'

One of the interaction models not really tackled in the current Notifications pattern is the 'side partner' model first introduced with Office Assistant back in Windows 95. Clippy and other agents were vilified as obnoxious and disruptive. However, a similar model was re-invigorated in the mobile world, where users are often given one-time introductory in-context information on various features in a new UI.

As with many trends, this mobile interaction is getting signficant traction in the web world. Walk Me is the most prominent example I've encountered recently by various PALs, but it is not the only one.

There are a lot of accessibility challenges with such assistance patterns. None seem insurmountable, but the patterns points to an even greater need for holistic treatment of the various aspects of notification patterns. Carbon has the opportunity to devise a consistent, predictable approach to all forms of notification.

Toolbars and tool regions

Another interaction, which is only nominally related to notifications, is also becoming more prominent in the cloud environment. This is the model of UI historically associated with Adobe and other composing products, where users interact with a central work area, with toolbars and resources positioned around the periphery (toolbars often the right side; resources often hierarchically arranged on the left). Task-based context -- including sometimes notifications -- are provided in these side panels. Navigation by mouse is straightforward. However, navigation by keyboard between the primary task and these panels can be complex or (in the worst case) prohibitively inefficient.

The same considerations which may make such interactions more usable and accessible are also highly relevant to notifications, so it makes sense to keep the compositional model in mind.

Obscuring other content

If a notification can appear on the screen over other content, it can potentially obscure the item with focus. There are some basic scenarios where this can occur:

1. the notification does not take focus and persists, thereby potentially obscuring components as users continue with their tasks
2. the notification takes focus, but the user is able to leave the notice without dismissing it, resulting in it again potentially obscuring focus in the future
3. a notification, positioned so it does not obscure content, persists on the screen (which seems fine), BUT the user modifies their content in some way (e.g., increasing the text or altering the text spacing) that results in the notification position now obscuring content.
4. The notifications accumulate, so that more of the UI is covered than with just one notice. Toasts potentially do this.

Banner and notification panels both seem to potentially address this challenge. Toast behaviour (where the notice goes away after a certain period of time) may also potentially work -- although non-persistent information has its own challenges.

The ability for a user to control notification behaviour may be a solution.

[mbgower]

Looking at the Usage information on the notifications component (as opposed to pattern), there seems to be a real pivot in behaviour based on whether any notification contains an interactive element (beyond the X to dismiss).
I feel like in the same way Carbon has come up with a Toggletip that allows child elements, the same might arise for a notification. It should likely be a different component. I'm wondering if Carbon has considered this, and what some of the qualities of each might be? For example, a tooltip does not have an X button to close, because it is not actionable. I'm wondering if there is a potential for some similar behaviour and visual distinctions between what you call an actionable notification and one that merely informs with no ability to do anything.
And of course, a modal dialog is beyond what I think of an actionable notification, since it MUST take user input before the user can proceed.