Accessible Notifications (in progress)

Introduction

For the purposes of this post I’m going to define notifications as messages that appear on the screen while using an application. Notifications can be difficult or impossible for sighted keyboard-only and users of assistive technologies to access. DOM positioning and the inclusion of controls like buttons and links pose significant challenges.

The various types of notifications are listed below.

Static notifications that only contain text or text and a close button

  • Non-user Initiated Static Notifications – Text Only.

    These are the simplest type of notifications because they are basically status messages. According to 4.1.3 Status Messages these should be presented to the user without focus management. Fortunately ARIA Live Regions are perfect for this task. Additionally, since the user did not initiate the notification by activating a control, there is no need to convey the state of a control such as a toggle button.

  • Non-user Initiated Static Notifications – Text and Close Button..

    Many designs for notifications include a close button. But often it is not necessary to use this button since many designs ensure that the notifications do not visually occlude any other part of the application. Non-sighted screen reader users will typically not benefit from using the close button. But if the usage of the the close button is critical, I recommend using a modal dialog rather than a notification. But if there is no need to use the close button I recommend removing it from the design. If it can’t be removed from the design, it should not be included in the live region since its accessible name will be part of the message screen reader users hear. For example, hearing an announcement like “your order has been shipped, close” will not make sense.

    http://www.chrislane.info/examples/notifications/1.html

  • User Initiated Static Notifications – Text Only.

    This is a simple case but since the user initiated the appearance of the notification, a button, link or other type control must have been activated. In this case, the control in question may require a state change that is communicated in an accessible manner. Focus management may also be necessary. For example, when interacting with a wizard, the user might activate a button to move to the next step in the workflow. While the user may hear a status message like “step 1 complete”, focus still needs to be moved to the most appropriate place in the view for the next step.

  • User Initiated Static Notifications – Text and Close Button

    This case is similar to the text only case regarding the possible need for additional state and/or focus management. But if it necessary for the close button to be activated for continued use of the application, a modal dialog should be used instead. If it not necessary, the notification can be implemented with and ARIA Live Region that excludes the close button.

  • Static Notifications – that visually occlude other parts of the application

Static notifications that contain text and controls other than a close button

  • Non-user Initiated Static Notifications – Text and Controls other than a Close Button

    This is where things become difficult. If a non-user initiated static notification contains controls other than close button, an ARIA Live Region will not provide immediate access to those controls for keyboard-only or screen reader users. It will only announce the accessible names for the controls as mentioned in the close button scenarios earlier. The typical solution for this is to use focus management to give keyboard-only and screen reader users immediate access to the newly added controls. But proper focus management requires a mechanism to place focus somewhere close to the part of the page the keyboard-only or screen reader user was reading if they choose not to use any of the newly added controls. For example, after activating the close button in a modal dialog, focus is usually returned to the control that activated the dialog. If that is not possible, focus can be set the nearest element that makes sense in the given context. But without a triggering element, or nearby alternative, there is no clear destination for focus to return to.

    So if neither ARIA Live Regions or focus management will work, what will? Here are couple of ideas.

    1. A Notifications Section.

      Providing a visible section with a visible heading for notifications on the page in combination with skip links to easily move focus to it is a simple way to ensure that keyboard-only and screen reader users can easily access any newly added controls that are part of a notification. We still need to use an ARIA Live Region, but not to deliver the notification itself but to inform screen reader users that a new notification has been added to the Notifications section. Screen reader users can then locate the Notifications section by finding its heading. Sighted keyboard-only users will see the new notification appear in the Notifications section and then Tab or use skip links to reach it.

    2. http://www.chrislane.info/examples/notifications/2.html

    3. Keyboard Commands

  • User Initiated Static Notifications – Text and Controls other than a Close Button

Ephemeral notifications that only contain text or text and a close button

  • User Initiated Ephemeral Notifications – Text Only
  • User Initiated Ephemeral Notifications – Text and Close Button
  • Non-user Initiated Ephemeral Notifications – Text Only
  • Non-user Initiated Ephemeral Notifications – Text and Close Button

Ephemeral notifications that contain text and controls other than a close button

  • Non-user Initiated Ephemeral Notifications – Text and Controls other than a Close Button
  • User Initiated Ephemeral Notifications – Text and Controls other than a Close Button