Briefly displaying a "Saved" toast in the lower right of the screen. Updating the count to "12 results found" after filtering a search form. These changes, readily apparent to those operating with a mouse and eyes, often fail to reach people using screen readers at all—an issue frequently flagged when audited for accessibility after delivering websites in client projects. Visual changes were implemented, but the design necessary to communicate those changes audibly was omitted.
For a long time, aria-live regions were the primary mechanism for communicating dynamic changes to assistive technologies. However, aria-live requires delicate handling and suffers from issues such as missed or overlapping notifications. To address this, the new ariaNotify() API has been proposed. In this article, we break down from a web production perspective where aria-live often falls short, what ariaNotify() aims to change, and how we should approach implementation in client work today.
Why visual changes fail to be announced
Screen readers fundamentally read out where focus is currently placed or where the user is actively reading through content. If the screen is discreetly updated somewhere else without the focus moving, users will not hear it. Toasts and search result count updates are textbook examples of changes occurring outside active focus.
The mechanism designed to communicate this is the aria-live attribute. When the content inside an area marked with aria-live="polite" is updated, screen readers are expected to announce that change. In practice, however, developers frequently encounter the following stumbling blocks.
First, announcements can be skipped. An aria-live region must exist in the DOM when the page loads. If the entire region is injected later via JavaScript, the changes made in that instance may not be announced.
Second, notifications can overlap and lack guaranteed ordering. When multiple changes occur within a short span of time, prior announcements may be cut off, making it difficult to predict what will be read.
Third, behavior depends heavily on the browser and screen reader combination. Even with identical markup, behavior varies across screen reading software, driving up testing and verification costs.
What ariaNotify() aims to change
As CSS-Tricks somewhat ironically described as the "Siren Song of ariaNotify()", ariaNotify() moves away from the indirect method of updating DOM content and praying it gets read aloud, aiming instead to let scripts directly command, "Please read this out right now."
// 構想段階のため API 名・引数は変わる可能性がある
element.ariaNotify("ファイルを保存しました", { priority: "normal" });The core concept is that the string you want read aloud and its priority can be passed independently from the display DOM. You are no longer bound by the constraint of aria-live where the text shown on screen must equal the text read aloud, making it straightforward to assign concise icons to the visual UI while providing contextual sentences to screen readers. Browser-level handling for notification ordering and overlapping is also being actively discussed.
However—and this is most crucial for client work—ariaNotify() is still in the standardization process, with limited browser support. The reason CSS-Tricks referred to it as a "siren song" is the implication that, while attractive, relying on it entirely right now is hazardous. Implementation strategies for live production sites today must be planned with this reality in mind.
Implementation strategies to adopt right now in client work
Even if a new API is appealing, deliverables must function reliably across modern browsers today. For client development right now, it is safest to approach implementation in the following order.
| Status | Recommended implementation today |
|---|---|
| Lightweight notifications such as toasts and save confirmations | Injecting text into a pre-existing aria-live="polite" region |
| Errors and alerts requiring immediate notice | aria-live="assertive" or role="alert" |
Using ariaNotify() | Limiting usage to progressive enhancement on supported browsers |
In other words, the strategy is to build the foundation with aria-live, which works reliably today, and use ariaNotify() as an enhancement to communicate even better when supported. This follows the same mindset as adopting new CSS capabilities on top of sensible fallbacks; the criteria discussed in our article on deciding whether to adopt modern native CSS features using Baseline applies equally to JavaScript APIs.
The key to ensuring aria-live works reliably is to keep the region present in the DOM from initial page load in an empty state, inserting only the content later.
<!-- ページ読み込み時から存在させておく（中身は空） -->
<div id="status" aria-live="polite" class="sr-only"></div>// 変化が起きたら、領域の「中身」だけを更新する
document.getElementById("status").textContent = "ファイルを保存しました";Real-world oversights encountered in client projects
On a membership service website where our company took over renewal work (keeping the company name confidential), a toast appeared in the lower right each time an action was taken on the post-login dashboard. While visually considerate, the toast was implemented by generating a new <div> element via JavaScript on every action, meaning screen readers announced neither "Saved" nor "An error occurred." Missing even error notifications is an unacceptable omission for a membership service.
Keeping the visual display logic intact, we established a single, permanent empty aria-live="assertive" region on the page and modified the implementation to route the same text into that region whenever a toast was shown. All we did was write the exact same message seen visually into the permanent container. This allowed major screen readers to announce notifications properly, alerting users audibly when errors occur. Regarding assistive technology support around forms, pairing this with the perspectives covered in our article on cognitive inclusion and accessible form design creates a cohesive experience from data entry all the way through result notification.
Where to begin
The starting point is to audit your current site for areas where the visual UI changes but focus does not move. Toasts, result count updates, autosave indicators, and asynchronously replaced error messages—all of these might be completely silent to assistive technologies. Simply preparing a single permanent aria-live region and funneling the visual message into it resolves most cases in modern browsers today. Once that foundation is secured, treating ariaNotify() as a progressive enhancement to deliver a superior experience on supported browsers is more than sufficient.
If your dynamic notifications are failing to reach assistive technologies, you have received accessibility audit findings regarding aria-live, or you need guidance on how much of a new API to adopt in production, reach out to us via GleamHub's contact form. We will inspect dynamic notifications on your current website and implement a rock-solid foundation for today alongside future-facing enhancements.
