As of today, several members of the aria working group have taken a look at or reviewed the spec PR, with one of the chairs approving the change with only editorial comments. Since no substantive comments have been made after this was opened for review, I feel that this spec PR is in a good state. While I am still awaiting review from representatives from Webkit and Firefox, at this point they have had sufficient time to raise issues if they had them, and since no issues were brought up when discussing the PR during working group meetings, I feel it is safe to move forwards with shipping this in chrome (and edge). Let me know your thoughts here, or if you have any questions. -Jacques
On Friday, August 15, 2025 at 1:45:19 PM UTC-7 Jacques Newman wrote: While I am still waiting for review and positions from Firefox and Webkit members of the Aria WG, I'm getting positive signals from the non-implementor members with a couple of lgtms with only editorial suggestions. As more reviews come in, I'll keep this thread updated. Add ariaNotify draft by janewman · Pull Request #2577 · w3c/aria <https://github.com/w3c/aria/pull/2577> On Wednesday, July 23, 2025 at 3:39:31 PM UTC-7 Chris Harrelson wrote: On Wed, Jul 23, 2025 at 2:23 PM 'Jacques Newman' via blink-dev < blin...@chromium.org> wrote: 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. I think it would be good to ask at the WG tomorrow how strong of an "implementation commitment" they need. If it's like the one in the WHATWG process, there just needs to be "interest <https://whatwg.org/working-mode#additions>" in the API, for which a positive standards position would suffice I think. Another question: has the editorial review & approval of the ARIA WG PR been completed? Looks like not yet from what I can see. I think that's important as well. *From:* Chris Harrelson <chri...@chromium.org> *Sent:* Wednesday, July 23, 2025 8:35 AM *To:* Daniel Bratell <brat...@gmail.com> *Cc:* Jacques Newman <jacques...@microsoft.com>; blin...@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 <brat...@gmail.com> wrote: LGTM1 /Daniel On 2025-07-23 00:00, 'Jacques Newman' via blink-dev wrote: *Contact emails* alm...@microsoft.com, jane...@microsoft.com, 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+...@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+...@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+...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH4PR00MB230211DB965B1A52330415848B5FA%40CH4PR00MB2302.namprd00.prod.outlook.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH4PR00MB230211DB965B1A52330415848B5FA%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. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/41c5b527-44db-46a9-85a0-0e1348af8c21n%40chromium.org.
