Skip to content

Using aria-live="assertive" for Flutter-web's SemanticsService.announce implementation #104109

Description

@marcianx

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.

Activity

  1. added
    engineflutter/engine related. See also e: labels.
    a: accessibilityAccessibility, e.g. VoiceOver or TalkBack. (aka a11y)
    platform-webWeb applications specifically
    frameworkflutter/packages/flutter repository. See also f: labels.
    on May 18, 2022
  2. goderbauer commented on May 18, 2022

    @goderbauer
    Member

    /cc @yjbanov @dnfield @chunhtai

    I wonder, do iOS/Android/Desktop have a polite way of announcing something via the announce API? If not, we'd have to figure out what to do when polite is specified on those platforms if we go with option 2.

  3. chunhtai commented on May 18, 2022

    @chunhtai
    Contributor
  4. goderbauer commented on May 18, 2022

    @goderbauer
    Member

    I think I am leaning towards option 2 and give developers the choice.

  5. added
    P1High-priority issues at the top of the work list
    on May 19, 2022
  6. yjbanov commented on May 19, 2022

    @yjbanov
    Contributor

    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.

  7. self-assigned this
    on May 19, 2022
  8. github-actions commented on Aug 10, 2022

    @github-actions

    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 -v and a minimal reproduction of the issue.

  9. locked as resolved and limited conversation to collaborators on Aug 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P1High-priority issues at the top of the work lista: accessibilityAccessibility, e.g. VoiceOver or TalkBack. (aka a11y)customer: googleVarious Google teamsengineflutter/engine related. See also e: labels.frameworkflutter/packages/flutter repository. See also f: labels.platform-webWeb applications specifically

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions