I'm requesting a TAG review of the AriaNotify API.
A new API, AriaNotify, enables content authors to directly tell a screen reader what to read. Without AriaNotify, ARIA live regions are the only mechanism available today that communicate content changes down to the accessibility layer so that users can hear about them. ARIA live regions are stretched far beyond their original use cases as authors struggle to use them in scenarios that they weren't designed for. AriaNotify is purpose-built to communicate to the accessibility layer for scenarios in which ARIA live regions are a poor choice. In the simplest scenario, the content author calls ariaNotify with a string to read.
We plan to add a permissions-policy that would allow authors to opt iframes out of AriaNotify. We are working on the implementation and draft spec but it is not yet finished. The relevant WHAT WG discussion is here: https://github.com/whatwg/html/issues/11004
Please let us know if the permissions-policy should be requested as part of a separate TAG review, or accepted as part of this one.
<!------------------------------------------------------------------------------------
CAREFULLY READ AND DELETE CONTENT BELOW THIS LINE BEFORE SUBMITTING
Use links to content rather than pasting text into this issue. Issues are ephemeral and most of the material we are asking for has long term value.
Please preview the issue and check that the links work before submitting. Please make sure anyone with the link can access the document. We may refuse to review anything that is not public.
¹ We require an explainer to give the relevant context for the spec review, even if the spec has some background information. An explainer must address user needs and contain examples of use. For more information, see our [explanation of how to write a good explainer](https://tag.w3.org/explainers/).
² A Security and Privacy questionnaire helps us understand potential security and privacy issues and mitigations for your design, and can save us asking redundant questions. See https://www.w3.org/TR/security-privacy-questionnaire/.
³ For your own organization, you can simply state the organization's position instead of linking to it. This includes items on [Mozilla standards-positions](https://github.com/mozilla/standards-positions), and [WebKit standards-positions](https://github.com/WebKit/standards-positions). Chromium doesn't have a standards-positions repository and [prefers](https://source.chromium.org/chromium/chromium/src/+/main:docs/standards/positions/GoogleChrome/README.md) to use comments from the teams that maintain the relevant area of their codebase.
⁴ Include links to [Chrome Status](https://chromestatus.com/), [Mozilla's](https://bugzilla.mozilla.org/), [WebKit's Bugzilla](https://bugs.webkit.org/), and trackers for other implementations if those are known to you.
-->
OpenedMar 31, 2025
こんにちは TAG-さん!
I'm requesting a TAG review of the AriaNotify API.
A new API, AriaNotify, enables content authors to directly tell a screen reader what to read. Without AriaNotify, ARIA live regions are the only mechanism available today that communicate content changes down to the accessibility layer so that users can hear about them. ARIA live regions are stretched far beyond their original use cases as authors struggle to use them in scenarios that they weren't designed for. AriaNotify is purpose-built to communicate to the accessibility layer for scenarios in which ARIA live regions are a poor choice. In the simplest scenario, the content author calls ariaNotify with a string to read.
Further details:
You should also know that...
We plan to add a permissions-policy that would allow authors to opt iframes out of AriaNotify. We are working on the implementation and draft spec but it is not yet finished. The relevant WHAT WG discussion is here: https://github.com/whatwg/html/issues/11004
Please let us know if the permissions-policy should be requested as part of a separate TAG review, or accepted as part of this one.
<!------------------------------------------------------------------------------------ CAREFULLY READ AND DELETE CONTENT BELOW THIS LINE BEFORE SUBMITTING Use links to content rather than pasting text into this issue. Issues are ephemeral and most of the material we are asking for has long term value. Please preview the issue and check that the links work before submitting. Please make sure anyone with the link can access the document. We may refuse to review anything that is not public. ¹ We require an explainer to give the relevant context for the spec review, even if the spec has some background information. An explainer must address user needs and contain examples of use. For more information, see our [explanation of how to write a good explainer](https://tag.w3.org/explainers/). ² A Security and Privacy questionnaire helps us understand potential security and privacy issues and mitigations for your design, and can save us asking redundant questions. See https://www.w3.org/TR/security-privacy-questionnaire/. ³ For your own organization, you can simply state the organization's position instead of linking to it. This includes items on [Mozilla standards-positions](https://github.com/mozilla/standards-positions), and [WebKit standards-positions](https://github.com/WebKit/standards-positions). Chromium doesn't have a standards-positions repository and [prefers](https://source.chromium.org/chromium/chromium/src/+/main:docs/standards/positions/GoogleChrome/README.md) to use comments from the teams that maintain the relevant area of their codebase. ⁴ Include links to [Chrome Status](https://chromestatus.com/), [Mozilla's](https://bugzilla.mozilla.org/), [WebKit's Bugzilla](https://bugs.webkit.org/), and trackers for other implementations if those are known to you. -->