Intent to Ship: ARIA Notify API

[Jacques Newman]

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

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?

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.

 

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 

 

[Daniel Bratell]

LGTM1

/Daniel

--
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.

[Chris Harrelson]

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?

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a7d368b-cc19-499b-8ed5-890a2a057797%40gmail.com.

[Jacques Newman]

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. 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, 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

[Chris Harrelson]

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. 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, 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" 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.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH4PR00MB230211DB965B1A52330415848B5FA%40CH4PR00MB2302.namprd00.prod.outlook.com.

[Jacques Newman]

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

[Jacques Newman]

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

[janewman via Chromestatus]

The [spec PR](https://github.com/w3c/aria/pull/2577) has a couple of LGTMs, including an approval from one of the chairs for the Aria Working group, Valerie Young. All comments have been editorial in nature, and I am getting strong positive signals from the group when the feature is brought up in the weekly working group meetings. With this, I feel it is safe to move forwards here, there has been more than enough time for anyone with substantive concerns or comments to speak up.

[Alex Russell]

LGTM2; thanks for being so responsive to all the concerns raised to date.

[Chris Harrelson]

LGTM3

--

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/4ce162a2-633d-4439-93bb-1576d6215b79n%40chromium.org.