8000 [ariaNotify] avoid pestering/annoyance of notifications, either too many or too irrelevant · Issue #2499 · w3c/aria · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
cookiecrook opened this issue Mar 26, 2025 · 5 comments
Open

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

cookiecrook opened this issue Mar 26, 2025 · 5 comments
Assignees
@keithamus

Comments

@cookiecrook
Copy link
Contributor

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.”
@alisonmaher
Copy link

Porting over my previous comment:

@cookiecrook Given that this would also apply to live regions, as well, and not just ariaNotify, should we open a general issue to discuss/explore this more broadly. Not sure where such an issue should live, but I do really like your idea around having some sort of DevTools logging to bubble such cases up to authors.

@Alexectramagneta

This comment has been minimized.

Sign in to view
@jnurthen jnurthen removed the Agenda label Apr 3, 2025
@jnurthen
Copy link
Member
jnurthen commented Apr 3, 2025

Dropping agenda as we should discuss this in this issue

@keithamus keithamus self-assigned this Apr 3, 2025
@Alexectramagneta

This comment has been minimized.

Sign in to view
@alisonmaher alisonmaher mentioned this issue Apr 15, 2025
Open
@spectranaut
Copy link
Contributor

Minutes from discussion in the ARIA working group two weeks ago: https://www.w3.org/2025/04/03-aria-minutes.html#2892

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@keithamus keithamus

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@cookiecrook @keithamus @spectranaut @jnurthen @alisonmaher @Alexectramagneta
0