[Screen reader] Review of aria-live region announcements

[microbit-robert]

Check for duplicates

• I have searched for similar issues before opening a new one.

Description

Screen readers behave differently when it comes to announcing content in aria-live regions. This is a review of the toast and 'move mode' announcements as of commit 74a36d7, so includes the change to make the move mode live region assertive. We can test VoiceOver, NVDA, JAWS and ChromeVox, so these are reviewed below, and we are happy to test changes going forward. It will be important to check the live region behaviour against any other screen reader that is being targeted.

Summary

As things stand:

• ChromeVox performs perfectly with the current implementation and the best out of those tested
• JAWS and NVDA perform well announcing move mode but do not announce toast messages or repeated message
• VoiceOver performs the worst having some issues dropping move mode announcements while block labels are being announced (this is a regression from changing the live region to assertive)

NVDA

• When inserting a block from the toolbox, move mode is correctly announced
• Move mode generally works, however:
  • If the text in the aria-live region is the same as the previous text, the message is not announced (this is a known issue with screen readers)
• Move announcements correctly interrupt themselves while moving a block around
• If a move is triggered while the block aria-label is being readout, move mode announcement correctly interrupts
• On accepting a move, the move announcement is truncated
• Toast messages are not announced at all

JAWS

Behaviour matches that of NVDA except for:

• When a block on the workspace is put into move mode, the block label is announced before move mode as opposed to NVDA which just announces the move

ChromeVox

• When inserting a block from the toolbox, move mode is correctly announced. If a toast message is shown at this point, the toast is announced before move mode. It might be preferable to have the move mode message first.
• If the text in the aria-live region is the same as the previous text, the message is correctly announced
• Move announcements correctly interrupt themselves while moving a block around. Toast messages and move mode messages also correctly interrupt each other.
• If a move is triggered while the block aria-label is being readout, move mode announcement correctly interrupts the block readout
• On accepting a move, the move announcement continues to be read out in full
• Toast messages are correctly announced, however, the readout includes the toast close button which seems irrelevant. The role of “Status” is also announced, which I don’t think adds anything.

VoiceOver

• When inserting a block from the toolbox, move mode is not announced. Note that it is announced after the block readout when the live region is set to “polite”.
• Move mode generally works, however:
  • If the text in the aria-live region is the same as the previous text, the message is not announced (this is a known issue with screen readers)
  • If a move is triggered while the block aria-label is being readout, move mode is not announced. Note that it is announced after the block readout when the live region is set to “polite”.
• Move announcements correctly interrupt themselves while moving a block around
• On accepting a move, the move announcement continues to be read out in full
• Toast messages are not announced at all

Next steps

We have looked at this issue in some detail, and will document the changes we have tried and the outcomes in additional comments below.

Reproduction steps

No response

Priority

No response

Stack trace

Screenshots

No response

Browsers

No response

[microbit-robert]

These are the implementations that I've tried and the results.

General notes

• It's possible that with the current implementation, NVDA, JAWS and ChromeVox only work quite well when it comes to interrupting speech at the right time because key presses cause speech interruptions
• Only the ChromeVox output changes when the aria-live region has the role of "status", but I'm not sure what this adds other than verbosity
• My wild guess on VoiceOver failing with aria-live="assertive" is that it attempts to the read out the message, but is immediately interrupted by the block read out due to the change in focus. All of the attempts below fallback to using aria-live="polite".

Using DOM elements that are added and subsequently removed

This version added DOM elements with the aria-live attribute, then had a setTimeout(..., 0) workaround to add the text content. This worked well for getting toast messages announced, and worked for repeating the same text multiple times. However, the announcements do not interrupt each over, therefore when moving a block, the screen reader output quickly become out of date.

Using two live regions (move and toast) and tracking previous messages with an object

This version used two live regions, one for move announcements and one for toast announcements. This version tracked the previous message for each region, and added a non-breaking space to the end of the content on repeated text to force the screen reader to output a repeated message multiple times. However, move mode and toast messages did not interrupt each other and it feels like they should or it is easy for the output to be out of date.

Using one live region and tracking previous messages with a variable

Similar to the version above but with a single variable to track the previous message for one live region. This worked well, except for user actions that triggered a move and a toast message at the same time (e.g., the first time you insert a block from the flyout), where typically only one of the two messages (or sometimes none) was announced.

Using one live region and tracking previous messages with a variable with a small debounce

Similar to the version above, but the function to add text to the live region has a small debounce of 10 ms, so that if it is called in quick succession, paragraphs are queued and then added to the live region div after a small delay. This fixes the 'insert from flyout' problem noted above.

This version is the only one that works well for all four screen readers tested. It still doesn't feel great and the debounce time might need to be increased for slower computers, but this is potentially one worth pursuing in the absence of better ideas.

Changes made for reference
Deployment

Append spans or paragraphs to one aria live region

This version continually appends text to one live region. You can change the assertiveness but changing the role of this region causes the screen reader to re-read everything in the live region. This relies on aria-atomic being omitted or explicitly set to false which means the screen reader should only output the new / changed content. This worked well for all screen readers except for NVDA with Chrome where there appears to be a bug where the aria-atomic value is not being respected and NVDA is reading out all of the content in the live region (it works with NVDA on Firefox) - if it were not for this bug, I would be convinced that this is the correct approach.

[rachel-fenichel]

Append spans or paragraphs to one aria live region
This version continually appends text to one live region. You can change the assertiveness but changing the role of this region causes the screen reader to re-read everything in the live region. This relies on aria-atomic being omitted or explicitly set to false which means the screen reader should only output the new / changed content. This worked well for all screen readers except for NVDA with Chrome where there appears to be a bug where the aria-atomic value is not being respected and NVDA is reading out all of the content in the live region (it works with NVDA on Firefox) - if it were not for this bug, I would be convinced that this is the correct approach.

When, if ever, do you clear the region?

Using one live region and tracking previous messages with a variable with a small debounce

From a design perspective I like this best. Is your concern that now we're managing the live-region instead of letting it manage itself?

[microbit-robert]

When, if ever, do you clear the region?

In my tests I never did this, but presumably this could be done at any point where you know that the upcoming text/span is not the same as that most recently pushed into the region.

From a design perspective I like this best. Is your concern that now we're managing the live-region instead of letting it manage itself?

I think I'm mostly concerned about the debounce potentially being a bit flakey.

[BenHenning]

When, if ever, do you clear the region?

In my tests I never did this, but presumably this could be done at any point where you know that the upcoming text/span is not the same as that most recently pushed into the region.

From a design perspective I like this best. Is your concern that now we're managing the live-region instead of letting it manage itself?

I think I'm mostly concerned about the debounce potentially being a bit flakey.

FWIW this type of behavior (debouncing) probably wouldn't work reliably on mobile (at least Android). My experience with Talkback is that even assertive regions can and will be ignored, especially if they are too spammy. Android exposes an API to be extra assertive but it's considered bad practice to really ever use it. I'm not exactly sure how Talkback's pickiness connects back to web view readouts, but I thought I'd mention at least one screen reader where I would expect potential issues.

It may be such that as long as we maintain 1 assertive ARIA live region and debounce it that nothing ever tries to interrupt--hopefully that's the case.

[BenHenning]

Also: my main concern with going back to polite is we can't guarantee the message is read out when we want it to be (at least per the spec, in practice however...) though ironically VoiceOver seems to be doing the opposite. That's really tricky honestly and I'm not entirely sure how to reconcile it. Perhaps we need to use polite until we encounter actual user issues with it and then adjust.