[Accessibility] NVDA does announce toasts, => toast global list is not an aria live region

[PhilippBaranovskiy]

Hello

Now the global toast list is just a div, while it should be an aria-live region.
Since it is, the screen reader will detect live region one the component is loaded, and then detect any changes inside the live region.

MDN provides explanation:

Simply including an aria-live attribute or a specialized live region role (such as role="alert") in the initial markup as it's loaded will have no effect.

It's true, the current implementation doesn't work with NVDA, for instance.

Also:

Dynamically adding an element with an aria-live attribute or specialized role to the document also won't result in any announcement by assistive technologies

They suggest that it should be implemented like Always make sure that the live region is present in the document first, and only then dynamically add/change any content.

I'm making a PR that aims to add that attribute to the component.
I've tested that with NVDA, please subscribe and have a look by the link I'm providing a little bit later.

Relative issues and PR:

1. ✅ Toast Messages Should Be Read by the Screen Reader on Display Toast Messages Should Be Read by the Screen Reader on Display #715
2. ✅ Accessibility/toasts Accessibility/toasts #780
3. ✅ Add aria-live="assertive" to EuiToasts Add aria-live="assertive" to EuiToasts #583
4. ⚠️ Screenreader doesn't announce that user is in a new space Screenreader doesn't announce that user is in a new space kibana#23885

cc @cchaos @snide

[snide]

Careful with this one. I remember trying to get aria-live to work like this and found that while it was semantically correct, the screenreader didn't announce the way I wanted it to. In general I've found aria live the most problematic of the standards and have to bypass it as often as I use it because browsers don't read updates correctly.

At least in the docs currently, toasts announce as you would expect. Looking at the code, we have aria-live on the toasts themselves and not the list. If I remember correctly it was because the list itself wouldn't update, so it required individual items to work correctly. Often I've used role="alert" in similar situations.

[PhilippBaranovskiy]

Thanks for pointing that out!
They might be sort of tricky, that's because of the algorithm of work. Actually, the toasts itself shouldn't be aria-live items, but aria-live items should be a live region which should contain toasts, however, then it needs to set a proper way of updating content!
That depends on what kind of updates are going to be there.
It may be a logger (and then no problem), or updater, then my new Eui component DelayRender helps here a lot! If you are up to it, let's discuss it deeply.

Anyway, the current implementation doesn't work in NVDA while the provided screenshot shows me the VoiceOver announcement.
The share of NVDA is big enough to take it into account.

[PhilippBaranovskiy]

@snide I will keep you posted, let's have a look at the final implementation once it's ready.

[PhilippBaranovskiy]

@snide so the final step is just to make a parent <div> as a aria live region by adding attr role="region",
and aria-live from a particular toast to the global list container.
VoiceOver works perfectly with that solution at the moment.
#2055