Decide on scope of “alert” component behaviour

[andrico1234]

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

[andrico1234]

Another thing worth noting, there was mention in previous issues that the goal for this component is for it to graduate into the HTML spec. Considering the uncertain future of live regions (see Aria 1.4 and Notification API), it might be worth changing the goal to instead develop an Open UI (web?) component that can adapt to future changes made to live regions.

[yinonov]

@andrico1234 is there a library of open-ui (web) components?

[andrico1234]

@yinonov The closest thing I could find is the platform directory, which seems like an incubator for elements before they land in the respective working groups

[aardrian]

Just this weekend @scottaohara penned a piece that gives useful context for multiple live regions per page, along with links to other resources: https://www.scottohara.me/blog/2022/02/05/are-we-live.html

I am not making any statement on this proposal with this link, only providing some additional detail for current support and behavior.

[colbywhite]

I'll preface my two cents by being honest about the fact that I'm not very adept at the nuance of accessibility. (I'm hoping getting involved with OUI helps me level up.)

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

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

My instinct is to say that these two bullet points are two separate concerns. I assume scenario no. 2 in the alert proposal (e.g. User has entered an invalid value into a form field) would be a valid use case for a standalone <oui-alert> component, i.e. the first bullet point. But that same <oui-alert> component could be reused by some sort of <oui-live-region> component. Thus the hypothetical <oui-alert> component can stand on its own and in conjunction with a live region.

However after reading through Scott's thorough blog entry, it certainly sounds like a standalone <oui-alert> might not be as needed as I thought. Let me ask a few questions that are likely coming from my own accessibility ignorance:

• If there's a live region somewhere else on the page, and you need an alert for a particular form input (i.e. scenario no. 2 from the alert proposal), then what? Wouldn't this contradict the guidance from @aardrian (i.e. one live region per page)? I would think multiple regions would be common, particularly with a form that has multiple invalid inputs.
  • Note: my wording there is based on the understanding that alert/log/status/etc etc are all live regions and thus having one of each would contradict that one-live-region-per-page guidance.
• It's not clear to me what the point of the different roles (alert/log/status/etc etc) are after reading through Scott's write up. In the demo most of the elements added to the single live region are of <div role=none> and the more precise roles aren't used. If the recommendation OUI wants to promote is to have a single region you add to with role=none element, what's the use case for the more precise roles?

After typing that out, I guess both of my questions are trying to nail down if/when/how the standalone roles should be used. If there is a valid case for them, then it seems like there should be a standalone <oui-alert> component. Minting a oui-live-region that follows the lessons from Scott's write up still would be valuable, but "in addition to" as opposed to "instead of".

Thoughts?

[andrico1234]

I think the biggest problem when it comes to creating a dedicated alert component is that AT behaviour for managing multiple live regions is poor. Not only is behaviour inconsistent between different screen readers, but the experience of having multiple alert regions stealing attention from the screen reader can be problematic.

If used correctly, option 2 can avoid the multiple live regions per page, by having web developers create the component once, and using whatever API it offers to add/remove messages from it.

The argument against creating a oui-alert component is that we're effectively making it easier for developers to misuse this pattern.

I think you're completely right in that the options aren't mutually exclusive though, but after the discussion in the proposal doc, it seems likely that option 1 could cause more problems instead of solving them.

[scottaohara]

some follow up points / clarifications to your comment, @colbywhite. i hope they help.

a role=alert would not be expected for exposing inline form error messages. It would be more suited to a persistent section of content on a page that would necessitate it being explicitly exposed as having an "alert" role. Inline error messages do not have this requirement, or expectation.

Rather, an inline error message needs to be associated with the form control it describes. This is typically done by use of aria-describedby by web authors now. Chromium will actually make a "live" announcement when an input's description is modified. Other browsers may need an aria-live attribute specified on the message to ensure it is automatically announced by screen readers... however, none of this constitutes the use of a role=alert. And using live regions on these individual messages can create a deluge of announcements if, for example, inline error messages were not displayed until someone tried to submit a form field.

regarding:

It's not clear to me what the point of the different roles (alert/log/status/etc) are after reading through Scott's write up. In the demo most of the elements added to the single live region are of <div role=none> and the more precise roles aren't used.

is seems that you were focusing on the messages that were being injected into the live region containers, rather than looking at the containing elements to see what role, if any, was used (some used aria-live attributes instead of a specific role). the different live region roles have different use cases, and are all defined in ARIA.

For elements that are being injected into a page but do not require being exposed with their own live region role, that's what aria-live is used for.

As mentioned in the explainer and elsewhere (not sure where), HTML already has the <output> element which is a role=status by default. So a new element proposal for simply communicating implicit ARIA live region roles would need a level of justification as to why it needed to exist, beyond possibly expanding the features of the current element?

And that sort of leads into a more general consensus conversation of "what is the actual component being proposed here?" Much of the research and references to the design systems seem to combine a series of separate concepts. E.g,, toasts, notifications/alerts, inline error messages, but one element for all of those will miss the mark on what's expected for each. Particularly because at the end of the day, a live region presently works best as a container element that messages are injected into it. Not as individual live region elements that are dynamically rendered on the page.

However, if a notification API is created, then the need for live region elements becomes far less important, as any arbitrary content made with any arbitrary element could be communicated via the notification API, and then really what you're left with is styled divs, paragraphs... modeless dialogs even. A specific element becomes less important unless you are specifically trying to achieve one thing. E.g., a location where messages can be dynamically injected into and there is a good reason as to why the role of that element needs to be communicated as a log, status, alert....

[colbywhite]

And that sort of leads into a more general consensus conversation of "what is the actual component being proposed here?"

Very interesting @scottaohara. I'm gathering this isn't as far as long as I assumed then. The proposal is titled Alert proposal and explicitly references the role=alert, hence why I assumed the goal was a component around that role and was focusing on the things being injecting into the region. But as you point out, that's not as clear cut.

Sidenote: it seems like Scenario 2 in the alert proposal might not really be related to an alert. I was a little hesitant about that scenario, but assumed my hesitancy was a factor to my very basic a11y knowledge. A note around that might clarify that scenario.

I'm going to fall back a bit on alerts then until it's fleshed out a bit more. My random two cents though would be to skip the middle man and go straight to the notification API. The design systems are likely mixing those separate concepts because, for those of us without advanced a11y knowledge, the concepts tend to bleed together for most devs. (Or maybe they bleed together for devs because the design systems have mixed them? 🐔 or the 🥚 as they say.)

But a notification API will probably be more involved.

[andrico1234]

However, if a notification API is created, then the need for live region elements becomes far less important, as any arbitrary content made with any arbitrary element could be communicated via the notification API, and then really what you're left with is styled divs, paragraphs... modeless dialogs even. A specific element becomes less important unless you are specifically trying to achieve one thing. E.g., a location where messages can be dynamically injected into and there is a good reason as to why the role of that element needs to be communicated as a log, status, alert....

I'm pretty much in agreement here. I've reached out to Travis, to help me understand better the intersection of use cases between the element proposed here and the Notification API.

I also understand the current name of this component is confusing as it seems to be moving away from being a wrapper over role="alert" and instead a static live region where elements are dynamically appended/removed.

Based on the outcome of this issue, we'd likely rename this component to something more appropriate

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.