Add options for testing aria-live announcements

[Paul-Hebert]

Assistive technologies use aria-live regions to announce important content changes to their users.

It would be great if Pleasantest exposed tools to help test aria live announcements. There are two approaches that could work:

Adding a new assertion

Something along these lines:

await expect('Preparing Learning Path').toBeAnnounced();

Adding more info to getAccessibilityTree

Another option would be to expose aria live regions in the accessibility tree. Perhaps by adding (aria-live) after the role or something?

Then in your tests you could check the aria-live region before and after an action and see that the text had changed (And presume it had been announced)

If we went this way should we probably provide info about whether the mode is polite or assertive. In follow-up cards we could also look into supporting aria-atomic, aria-relevant, aria-busy, etc.

---

I'm not sure which of these I'd prefer from a test writing perspective. It would be awesome to have both options, but that obviously adds complexity. Either one could solve for this use case.

[calebeby]

@Paul-Hebert Would this assertion:

await expect('Preparing Learning Path').toBeAnnounced();

pass only if the element with aria-live had just been changed (so that it would be announced)? Or would it pass as long as it has aria-live set?

Maybe another way of asking, if you did this:

await expect('Preparing Learning Path').toBeAnnounced();
await expect('Preparing Learning Path').toBeAnnounced();

Would it only pass if it had been announced twice, or would it pass even if it hadn't been announced (just if it has aria-live)?

[Paul-Hebert]

Or would it pass as long as it has aria-live set?

This seems like it could be misleading to me.

Sometimes UIs need to announce the same message multiple times in a row. This is tricky to do, and it would be nice to be able to confirm it was actually re-announced, and not just still populated with the same text.

Ideally it would only pass if it just changed.

Maybe this could be handled with a spy syntax somehow? (I'm not super familiar with these but have used these to listen for events before. Perhaps we could listen for the content changing?)

---

Revisiting the a11y tree option: It would be interesting to be able to show whether the value changed recently in tree output. e.g. (aria-live: polite | changed) (or something)

Perhaps the changed attribute could show if the value had changed:

• Since the last time you checked the a11y tree
• If you haven't checked the a11y tree yet, then if it has changed since the content first rendered?

(I don't have a sense of how or if this would work in the codebase. Just brainstorming what could be helpful from a dev perspective)