Decide on scope of “alert” component behaviour

Based on the discussion in the alert proposal doc, there are two paths we can go down in terms of component behaviour.

1. To mint components that allow web developers to add/remove discrete live regions. Examples 1 and 2.
2. To mint a single “live region” component that exposes methods to add/remove messages within the region. Example 3

For this issue, I propose that we take the latter option.

The former approach of minting a single alert , status, message component prevents developers from having to apply aria tags, but doesn’t prevent screen reader issues that come about from live region misuse, like:

• Multiple assertive live regions updating simultaneously
• Live regions being added after page load
• Alerts flushing the message queue
• Ignorantly overusing assertive live regions

In the proposal doc, both Adrian Roselli and Scott O’Hara give their reasons as to why the second pattern plays much more nicely for screen readers.

Generally we recommend one live region per page, and flow in the content as needed. Then the SR need only monitor one and need not make up its own rules about how to handle competing regions. - Adrian

this [multiple alerts being added at the same] is another thing that can happen when multiple instances of live regions are used on a page. different components firing off their own live region messages. It's awful, and it happens all the time. Making something easier for developers to do that seems a huge mistake. - Scott

This corroborates with my experiences using VoiceOver, as the latter implementation handles new messages much more gracefully.

Scott has a wonderful codepen that shows how different screen readers handle different live regions patterns.

David Lhur was kind enough to test using NVDA and had the same experience:

The first finding is that only example "3: Single live region" actually announces the alerts. I'm pretty sure this is because NVDA (and potentially other screen readers or assistive technology) rely on a static live region to be present on page load for it to register and announce changes.

This pattern could be used to display rolling updates about an application’s status. Like status updates for a file upload, network state, or responses to other asynchronous actions.

By giving web developers the tools to manage screen reader interruptions better, it makes it easier to adhere to WCAG 4.1.3, namely around making users aware of important changes without interrupting work.

One important thing to note is the discussion around live regions changes in Aria 1.4. There is also newly specced Notification API, which looks to solve a number of issues with live regions in the browser. With this in mind, it also adds a third choice to the two presented above, and to do nothing until live regions become more stable.

Note: After resolving this issue I’ll also be creating tickets around:

• API specifics
• Component composition
• Component behaviour (focus, stacking, dismissing)
• Component naming (again 😅)

So I hope to avoid diving into the above too much for this particular issue

Start with the linked alert proposal and compare examples 1, 2, and 3, including the cited screen reader findings from VoiceOver and NVDA. The issue is done when the project decides which live-region behavior to pursue; API, composition, focus, stacking, dismissing, and naming are explicitly deferred.