feat: aria live region for announcements

[mikeharv]

This adds an aria live region for announcing updates on Blockly. This was partially backported out of the screen-reader branch.

The basics

• I validated my changes

API verified by testing announcement of toast changes via uncommitted code.

The details

Resolves #9632

Fixes

Proposed Changes

During inject(), we will create a displayed-but-user-invisible <div/> with id blocklyAriaAnnounce which is configured as an aria live region with passive priority. Other parts of Blockly will be able to call announceDynamicAriaState with text to add to this region to be read by assistive technologies. An asynchronous timeout is used to manage replacing outdated pending announcements with the latest update.

Reason for Changes

This will give us a centralized place to announce dynamic state changes and information that cannot otherwise be conveyed.

Test Coverage

No testing changes yet. I plan to add tests to confirm the expected functionality of announceDynamicAriaState() as we start using with things like move mode and toasts.

Documentation

N/A

Additional Information

[BenHenning]

Thanks @mikeharv! Had some initial thoughts--PTAL.

Separately for testing, I think it would still be a good idea, if possible, to try and add at least some fundamental tests for the new announcement behavior. Some things which are hopefully testable and could be quite valuable to avoid downstream issues:

• The live region is polite.
• The live region is displayed (i.e. not display: none since this will then be ignored by screen readers).
• That subsequent announcements even with the same text are unique from the last (e.g. due to the additional non-spoken character being toggled).
• The general behavior of the region correctly announcing.

It would also be helpful to test that the region updates its role and value after a delay but I'm not sure how easy that one is to check. This directly fixes a somewhat tricky-to-debug issue that micro:bit found and fixed, so a regression test for it is definitely a nice-to-have (and not something I think we can assume works correctly just from other tested functionality that eventually uses dynamic announcements).

[BenHenning]

This should be omitted. It's actually wrong on the experimental branch and for fairly nuanced reasons (essentially it's invalid to mark an element as having the presentation role when any of its children are actually interactive for the screen reader; doing so will cause this element to get a default role instead).

[BenHenning]

For this & the other changes in this file: is it possible perhaps to adapt the API the one proposed in the WIP screen reader design document? Specifically this section:

https://docs.google.com/document/d/1-q0paWfV9qYWoZKWb9BpcfYOy3xYZtvcLyuuD61qHXw/edit?tab=t.0#bookmark=id.a3l9k4e1tah4

That was written after analyzing the approach taken in the experimental branch, considering micro:bit's changes, and other longer-term considerations. If there's an aspect of the design that doesn't work then it'd be great to discuss (e.g. via chat and/or comments directly on the doc) so that the doc and code end up being close to the same.