Repository navigation
Using aria-live="assertive" for Flutter-web's SemanticsService.announce implementation #104109
Description
Activity
- addedengineflutter/engine related. See also e: labels.flutter/engine related. See also e: labels.a: accessibilityAccessibility, e.g. VoiceOver or TalkBack. (aka a11y)Accessibility, e.g. VoiceOver or TalkBack. (aka a11y)platform-webWeb applications specificallyWeb applications specificallyframeworkflutter/packages/flutter repository. See also f: labels.flutter/packages/flutter repository. See also f: labels.
on May 18, 2022 I have not tested it but there is this iOS https://developer.apple.com/documentation/uikit/uiaccessibilityspeechattributequeueannouncement?language=objc
Reacted by Michael GoderbauerI think I am leaning towards option 2 and give developers the choice.
- addedP1High-priority issues at the top of the work listHigh-priority issues at the top of the work list
on May 19, 2022 I agree that option 2 is the way to go. If the framework-side API makes assertiveness level an optional parameter, I would also default to assertive. My reasoning is that if developer decides to make a verbal announcement, there may not be a written equivalent of it anywhere in the UI. Otherwise, they would use a live region or some other way to inform the user. If audio announcement is the only source, missing that would cause the user to lose a piece of potentially critical information.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.- locked as resolved and limited conversation to collaborators
on Aug 10, 2022
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 toaria-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:
aria-live="assertive", ORaria-live="assertive"element.