ariaNotify API

[keithamus]

WebKittens

@cookiecrook @twilco

Title of the spec

ARIA Notify

URL to the spec

https://github.com/w3c/aria/pull/2211

URL to the spec's repository

https://github.com/w3c/aria

Issue Tracker URL

No response

Explainer URL

https://github.com/WICG/accessible-notifications

TAG Design Review URL

https://github.com/w3ctag/design-reviews/issues/713

Mozilla standards-positions issue URL

https://github.com/mozilla/standards-positions/issues/1049

WebKit Bugzilla URL

No response

Radar URL

No response

Description

This proposal adds a new method to Element called ariaNotify which will leverage new a11y APIs to allow fine-grained control of notifications to AT.

It is being actively prototyped in Chrome, developed within Microsoft.

[cookiecrook]

Watching with interest. No WebKit-official position yet.

[cookiecrook]

Discussions ongoing:

• https://github.com/w3c/aria/discussions/1958

[marcoscaceres]

Adding @twilco for visibility.

[janewman]

Given feedback from developer trials, we are looking toward shipping this feature in Chromium. @cookiecrook, do you have any updated thoughts or positions on the ariaNotify API?

[cookiecrook]

WebKit position is:

• position: support (with concerns)

Concern flags are:

• concern-portability: some aspects of the roadmap rely on native API that doesn’t yet exist on Mac, for example. The plan is to add the needed APIs to implement it fully in WebKit when possible, and have other implementors adopt those in Chromium/Gecko once available. A concern is that Chromium could ship a partially-working version using existing APIs in the meantime, and developers may think this is the best experience they can get. Likewise, the Mac API supports passing loc/lang in a better way that the Windows and Linux APIs currently allow. See next.
• concern-internationalization: method should include lang/loc rather than chaining this to the posting DOM element’s language, but only the Mac APIs support this. ATK, UIA, MSAA, and IA2 don’t yet allow lang disambiguation in announcement APIs, and there is no roadmap for this change, ... v1 also defers SSML which could solve some pronunciation ambiguities (e.g. homonyms), whether due to locale or otherwise.
• concern-annoyance: misuse of this API may annoy or pester the user (a larger version of the same problem exists with Live Regions); browsers and/or assistive technologies should allow users to disallow usage by domain, but the spec should not be prescriptive about how this annoyance remediation is achieved. This is an opportunity for innovation and competitive differentiation.

Other notes where a concern did not align with a specific label:

• [Update: done] Spec should document what happens if notifications are posted on hidden elements.

A lot of ongoing discussions and other v1-deferred features are cross-referenced in ARIA #1958.

• https://github.com/w3c/aria/discussions/1958

Thanks for working hard on improving this @alisonmaher, @janewman, @douggeoffray, @scottaohara, @keithamus, et al. The closer we got, the more we argued over smaller and smaller details. While there is more work to be done, it's a much needed improvement over Live Regions, and it includes flexibility for continued iteration. Congratulations on getting this one to the threshold!