Bye, live regions. Hello, ariaNotify()

In September 2026, ariaNotify() was introduced as a new web API method to replace live regions. We are going to learn when we have to use it, which compliance criteria it meets and its benefits.

Hello, ariaNotify() method!! The title might be a clickbait, because we are far from replacing live regions, buuut... I am super excited about this new feature. I have been waiting for it since 2024 when it was announced in the WAI-ARIA 1.3 draft and it finally becomes baseline, in September of this year (2026) having complete support on Chrome, Firefox, Edge and Safari. So, you might be wondering why the hype, let's find out.

What is ariaNotify()? It is a web API's method that was presented as a programmatic way to trigger screen reader announcements. Yes, same thing as live regions, but the main difference is that live regions are attached to a DOM element and to achieve this now we have to inject hidden text into a DOM element where the change lives, therefore it only announces a text when there is a structural modification on the content. On the contrary, ariaNotify() queues the text to be announced by screen readers using JavaScript.

Markup of Live Regions

A summary of how live regions works nowadays. They need a combination of HTML + CSS + JavaScript to work properly.

<!-- an empty DOM element -->
<p role="status"></p>

// Then, injects the upate on the empty DOM element
const region = document.querySelector('[role="status"]')
region.textContent = '3 results'

Roles

• role="status": it is used for text that are advisory and not important enough to interrupt. It implies aria-live="polite" and aria-atomic="true".
• role="alert": it is used for important and/or time-sensitive text and it interrupts what the screen reader is currently saying. It implies aria-live="assertive" and aria-atomic="true".
• role="log": it is used for new entries in order, like a chat or live updates. It implies aria-live="polite".

WAI-ARIA

• aria-live: it has three values, polite which waits until the user is idle, assertive which interrupts what the user is perceiving, off which indicates that the changes on a region will only be announced when the user focuses on it.
• aria-atomic: its value can be true which means that the whole region will be announced when any part of it changes, or false which means that only the part of the region that changes is announced, for example, a clock going from 17.33 to 17.34, only the “34” will be announced.
• aria-busy: it is used on live regions that might be modified to let the user know when they have been modified. Its value can be true which tells the screen reader that it may wait until the changes are finished before announcing them, or false which means that nothing happens and nothing will be announced until the task is finished.
• aria-relevant: it is an optional attribute of live regions and it is just a suggestion to assistive technologies. Its values can be additions which refers to element nodes that are added to the accessibility tree within the live region, all, which it is a shorthand for additions removals text, removals which refers to any text content within the live region that is removed from the accessibility tree, or text which refers to text content or a text alternative that is added to any descendant in the accessibility tree of the live region.

Markup of ariaNotify()

element.ariaNotify('Draft saved.', { priority: 'high' })

1. Host element or document It is the element that will contain the announcement. It could be the Element in the accessibility tree, or the Document.
2. Method ariaNotify() The method itself. It is called on the host and it contains the announcement and the options.
3. Announcement 'Draft saved.' Required. It is the announcement text. Without it there is a TypeError.
4. Options { priority: 'high' } Optional. If it is omitted or a value that is not on the dictionary is being placed, the value by default would be ‘normal’.
5. Priority priority: 'high' | 'normal' normal, the default, is spoken after what is being spoken; high interrupts it.

Parallels with Live Regions

Live Region

<p role="status" aria-live="polite" aria-atomic="true"></p>

<p role="alert" aria-atomic="true"></p>

const polite = document.querySelector('[role="status"]')
const assertive = document.querySelector('[role="alert"]')

polite.textContent = 'Draft saved.'
assertive.textContent = 'Could not save the draft.'

ariaNotify()

<button type="button" lang="en">Save draft</button>

const element = document.querySelector('button')

element.ariaNotify('Draft saved.')
element.ariaNotify('Could not save the draft.', {
  priority: 'high',
})

In my opinion, the ariaNotify arrived to simplify the knowledge around announcements. In the past, having to communicate the knowledge about live regions was the biggest challenge for accessibility experts so having a method that with a single line of code covered the screen reader announcements without without hardcoding hidden text is refreshing.

Live Regions vs ariaNotify(): Use Cases

In this section, we will learn with use case examples how ariaNotify() simplifies the work and meets the WCAG success criterion to be compliant.

Here you can test the examples

Should I Document or Should I Element?

Neither of the MDN page for ariaNotify() in Document nor the MDN page for ariaNotify() in Element make a clear distinction between whether to attach the ariaNotify method to the Document or to the Element, but we can state that the choice is about the message per se. Based on that, I created the following table to help decide where to attach the method based on semantics and context.

Another thing worth mentioning is that the language of the announcement by default is, it comes from the lang attribute on the html element. If you want a dedicated section of the page to have a different language, set it explicitly.

Reusable and Global Solution for Announcements Using Just ariaNotify()

In my lib of methods, last month I implemented a reusable function to dispatch announcements programmatically using the ariaNotify() method.

1. A function to check if the native HTML element supports ariaNotify()

   export const hasAriaNotify = () =>
     typeof Element !== 'undefined' && 'ariaNotify' in Element.prototype

1. Create a type (if you are using TypeScript) to tell TypeScript the method may exist and what it takes.

   type Notifier = {
      ariaNotify?: (announcement: string, options?: { priority: Priority }) => void
    }

1. Then we have to create a notify function

   export function notify(
      from: Element | Document,
      message: string,
      priority: Priority = 'normal',
    ) {
      const native = hasAriaNotify()
      const send = () => {
        (from as unknown as Notifier).ariaNotify?.(message, { priority })
      }
      if (native) return send()
    }

• The function has 3 mandatory parameters: from which checks if the method is being attached to an Element or Document, message which is the string of texts to be announced and priority which is the type of announcement that the screen reader should do.
• If native is true, we are going to attach the method to the Element/Document and dispatch the action.
  1. The reusable function can be used in the following way:

   notify(bar, 'report.pdf uploaded.')

Screen Readers

Click here to discover how screen readers announce the announcements of ariaNotify method

WCAG 2.2 Success Criterion - Level AA

Browser Support

According to MDN, this is the list of browsers that support ariaNotify on their latest update since September 2026. Oldest versions might not support ariaNotify.

• Chrome version 141
• Edge version 141
• Firefox version 150
• Opera version 125
• Safari version 27
• Chrome Android version 141
• Firefox Android version 150
• Opera Android version 93
• Safari on iOS version 27
• Samsung Browser version 30
• WebView Android version 141
• WebView on iOS version 27

Resources

• https://developer.mozilla.org/en-US/docs/Web/API/Document/ariaNotify
• https://developer.mozilla.org/en-US/docs/Web/API/Element/ariaNotify
• https://w3c.github.io/aria/#ARIANotifyMixin