My thoughts on those questions: 1. AriaWG requires at least one implementation and one commitment to implement before any spec change can be merged, see: process.md<https://github.com/w3c/aria/blob/main/documentation/process.md#stage-four-merged>. This spec PR is on the agenda for tomorrow’s meeting, if it were approved and we got positive signals from (2) (but no commitment) how would you feel about moving forward? 2. I’m actively engaging with them in the Mozilla standards positions issue<https://github.com/mozilla/standards-positions/issues/1049>, I think the latest iteration of the spec and explainer will alleviate the concerns they had with the older versions of the API.
Please let me know if you have any other questions, concerns, or feedback! -Jacques From: Chris Harrelson <chris...@chromium.org> Sent: Wednesday, July 23, 2025 8:35 AM To: Daniel Bratell <bratel...@gmail.com> Cc: Jacques Newman <jacques.new...@microsoft.com>; blink-dev@chromium.org Subject: [EXTERNAL] Re: [blink-dev] Intent to Ship: ARIA Notify API Hi, Two questions: 1. The spec PR is still open, I'd like that to be finished before shipping. 2. The Mozilla position references an incomplete design, but those comments seem old and have been superseded by more recent discussion on the issue. My assumption is that once (1) is finished, the position will likely move to positive? On Wed, Jul 23, 2025 at 8:12 AM Daniel Bratell <bratel...@gmail.com<mailto:bratel...@gmail.com>> wrote: LGTM1 /Daniel On 2025-07-23 00:00, 'Jacques Newman' via blink-dev wrote: Contact emails alma...@microsoft.com<mailto:alma...@microsoft.com>, janew...@microsoft.com<mailto:janew...@microsoft.com>, leo...@microsoft.com<mailto:leo...@microsoft.com> Explainer https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/AriaNotify/explainer.md Specification https://github.com/w3c/aria/pull/2577 Design docs https://docs.google.com/document/d/1tFT-4_sDvgnZoS8AYEcQquXzqAYaoB53DBH0C2T5rMk Summary ariaNotify provides a JavaScript API that enables content authors to directly tell a screen reader what to read. ariaNotify improves reliability and developer control compared to ARIA live regions, allowing for announcing changes not tied to DOM updates. This enables more consistent and ergonomic accessibility experiences across dynamic web applications. Iframe usage of this feature can be controlled via a permission policy "aria-notify". Blink component Blink>Accessibility<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EAccessibility%22> TAG review https://github.com/w3ctag/design-reviews/issues/1075 TAG review status Issues addressed Risks Interoperability and Compatibility Gecko: Defer (https://github.com/mozilla/standards-positions/issues/1049) WebKit: No signal (https://github.com/WebKit/standards-positions/issues/370) Web developers: Positive (https://github.com/w3c/aria/issues/832) Blog post asking for the feature: https://www.nicchan.me/blog/please-can-we-have-aria-notify/ See section after the I2S template for more web developer verbatim feedback. Other signals: WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? None Debuggability I have verified that devtools autocomplete works as expected when the feature flag is enabled. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? No This API requires platform specific APIs to communicate the notification to screen readers, and this has not yet been implemented in ChromeOS. Is this feature fully tested by web-platform-tests<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>? No Web platform tests do not currently have the ability to monitor platform-specific accessibility APIs, [Acacia AAM](https://github.com/Igalia/rfcs/blob/wpt-for-aams-rfc/rfcs/wpt-for-aams.md) will close this gap and allow for testing of such features within WPT Flag name on about://flags Finch feature name AriaNotify Rollout plan Will ship enabled for all users Requires code in //chrome? False Tracking bug https://issues.chromium.org/issues/326277796 Estimated milestones Shipping on desktop 140 Shipping on Android 140 Anticipated spec changes Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way). All open spec issues can be resolved with backwards compatible additions. Recent conversations in the tag review showcase what an backwards-compatible extension might look like and the Mozilla standards position thread go over all of the open issues and how they can be resolved in the future in a backwards-compatible way. Open Issues link: https://github.com/w3c/aria/issues?q=is%3Aissue+is%3Aopen+%5BAriaNotify%5D Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5745430754230272?gate=5410577665490944 Links to previous Intent discussions Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH2PR00MB0680B14C1978202FF59CF7D3F2239%40CH2PR00MB0680.namprd00.prod.outlook.com This intent message was generated by Chrome Platform Status<https://chromestatus.com/>. Quotes from Web Developers: >From Steve at Desmos, a graphing calculator web application: “We are enthusiastic about integrating the new ariaNotify() API into our suite of Desmos tools. Across our platform—including in our customized fork of the open-source MathQuill equation editor, our graph sonification feature known as Audio Trace, and interactive geometry construction tools—we frequently provide screen reader users with real-time feedback via custom spoken messages. Historically, we have implemented these notifications by updating hidden document fragments with aria-live attributes. While this approach has served us reasonably well, it has a significant limitation that has long remained unresolved: screen readers will not re-announce the same message, even if the user explicitly requests it. This presents a notable usability issue. For example, if a user types the same digit repeatedly, navigates through a list of identical elements, or invokes a command to re-speak the most recent message, screen readers often remain silent. In minor cases, this forces users to take indirect actions just to hear the content again, while in more severe instances, it creates confusion or the appearance of a software defect beyond our control. The ariaNotify() API represents a promising and long-overdue improvement. Assuming timely and consistent adoption by browser and assistive technology vendors, this new mechanism will allow us to reliably deliver repeated announcements when appropriate—eliminating the need for fragile workarounds and improving the overall accessibility and responsiveness of our tools.” -Steve >From Sarah Higley on Fluent, a framework developed by Microsoft: "We have already implemented ariaNotify in Fluent on browsers where it is supported, in lieu of our DOM-based notification utility. The ariaNotify implementation gives us a more robust announcement utility in several key aspects: It works even when a modal dialog is open on the page Managing multiple notifications in succession is more robust across platforms It requires significantly less code, testing, maintenance, and edge case handling from our side. Debugging live region announcements consistently accounts for a disproportionate amount of debugging effort and bugs especially from our partner teams, and transitioning more and more towards only supporting the ariaNotify implementation would be a big time saver for us, and deliver a more robust experience to our users.” -Sarah Higley -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org<mailto:blink-dev+unsubscr...@chromium.org>. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH4PR00MB2302D315E668B3CD0168C9C98B5CA%40CH4PR00MB2302.namprd00.prod.outlook.com<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH4PR00MB2302D315E668B3CD0168C9C98B5CA%40CH4PR00MB2302.namprd00.prod.outlook.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org<mailto:blink-dev+unsubscr...@chromium.org>. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a7d368b-cc19-499b-8ed5-890a2a057797%40gmail.com<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a7d368b-cc19-499b-8ed5-890a2a057797%40gmail.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH4PR00MB230211DB965B1A52330415848B5FA%40CH4PR00MB2302.namprd00.prod.outlook.com.
