Use case

I'm working on a custom type of editor in Flutter and need to make it accessible across various platforms (flutter-web being the focus of this issue). The editor's content is rendered as an image and renders its own custom cursor. To make it accessible, I want to vocalize similarly to how a native text field would vocalize as the user navigates through it or edits it, but adapted to the semantics of my widget.

Existing custom editors (e.g. accessible web math editors) that I have tested vocalize feedback to the end user using a hidden element with aria-live="assertive" on it. This vocalization happens directly due to user action and uses "assertive" to ensure that the user receives that feedback as compared to aria-live="polite" which doesn't seem to vocalize in some cases (especially on VoiceOver). More specifically, this editor is not a widget vocalizing background auto-updates where "poilte" would be more appropriate.

Flutter's accessibility announcer service seems the ideal way to do these vocalizations. However, flutter-web implements the vocalization using an aria-live="polite" element. I recognize the spirit of avoiding the misuse of "assertive" announcements for background updates, but the case of feedback above due to direct user action, "assertive" seems more appropriate to ensure the user receives the feedback.

Proposal

Please either:

1. Modify the current implementation to use aria-live="assertive", OR
2. Add an additional argument to the announcer service to support assertive vocalizations and implement it using an aria-live="assertive" element.