Skip to content

[ariaNotify] avoid pestering/annoyance of notifications, either too many or too irrelevant #2499

Open
@cookiecrook

Description

@cookiecrook

Moved at @alisonmaher's request from:

AriaNotify should avoid pestering/annoyance of notifications, either too many or too irrelevant

I understand many aspects of the ariaNotify proposal (types, notification IDs, element-scopes, priority, division of critical vs interruptible text) are intended to reduce the annoyance of live regions and allow some level of verbosity or relevance control, particularly in the scenarios where irresponsible misuse equates to the level of abuse.

However, I also see a primary goal of the API to be “simpler,” easier to use than Live Regions, etc, which could lead us (even with the best of intentions) to an even-more abusable API for speech and braille announcements.

What follows is a list of known severe misuse scenarios that have proven annoying to screen reader users, so annoying that Apple engineers have implemented VoiceOver prefs to shut off live region notifications entirely. We’d like to provide a path to give users incentives to enable some types of helpful notifications while also giving them sufficient control to disallow abusive misuse, but the live regions API is vague enough that it’s differentiate these unwanted notifications from genuinely useful notifications.

Examples of misuse/abuse of Live Regions that should be disincentivized with a new API

  • live regions in advertising containers announcing irrelevant or unwanted content
  • timers or progress indicators using polite or assertive notifications, rather than “off”
  • extra chatty “log” containers, particularly that conflict with the primary content… For example, a social media live stream (Twitch, Instagram, etc) that displays excessive amounts of “likes” or comments, such that the main audio is trampled by live regions notifications

Specific examples:

  • This Texas Monthly article misuses an assertive live region to count down an ad, making the webpage unusable.
  • Numerous examples of custom audio and video players on the web have added role=status to the timecode element (0:42) which updates every second, making the video and other page content unusable.

Miscellaneous musings of how to address these and other misuse scenarios.

  • Some ideas already mentioned in the ariaNotify discussion thread (types, notification IDs, element scoping, priority, division of critical vs interruptible text, etc.) would allow more granular control by the web engine or downstream AT
  • “ignore ongoing notifications from [this labeled control] or [from the site altogether]” similar to social media site (Slack, etc) features for “mute notifications for this thread”
  • Disallow some usage (perhaps disallowing simple notifications) fired on major elements (document, body, main?) without more clarifying information like a notification ID, type, or other scoping metadata.
  • Require UAs to log errors, warnings, or debug messages to the browser console for certain excessive intervals.
  • Some implementors may object entirely to extra error or warning logging, and specifics of these intervals would be arguable, so perhaps test the extreme cases and leave intermediate triggers as an implementation detail?
  • As an extreme case, any quickly repeated notification without a proper timer role or percentage scope (less than 1s) could be considered an error, as most of the speech notifications would be trampled before completion.
  • Perhaps also number of notifications within some time period (5 times within 20s?) could be considered a warning.
  • Debug logging (including use-presented string) for all AT notifications (including Live Regions and the Web Speech API utterances), so excessive examples could be caught by QA for the site?
  • User prompt (non-blocking) on first attempt (similar to privacy APIs for location API and default browser notifications) allowing user to allow or disallow AT notifications
  • Is so, how much should be in the browser, and how much in the AT?
  • If user has previously disallowed notifications (or live regions) at the system level, this could be a gentle way to alert them that “this site, which you use daily, might not be misusing live regions like those other sites that caused to to disable them outright.”

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions