The New Power We Probably Shouldn't Have
There's a fresh method in the WAI-ARIA 1.3 spec called ariaNotify(), and it does something deceptively simple: it tells screen readers to speak. Programmatically. On demand. No form submission. No page load. Just JavaScript deciding what gets narrated and when.
I built a real-time dashboard for a client last year—think financial data, live updates, that sort of pressure cooker. We used aria-live regions back then, and they worked fine, mostly. But fine has limits. The timing was unpredictable. Sometimes announcements stacked. Sometimes they were swallowed by other page noise. We wanted control. Now we might actually have it.
Why I'm Both Excited and Skeptical
- You can finally announce exactly when something matters
- No more guessing whether a subtle UI change will get noticed by assistive tech users—just tell them
- The implementation is straightforward enough that even junior developers won't immediately break it
- But—and this is the real tension—you're now responsible for managing screen reader timing at the application level, which means you can absolutely mess it up in ways that didn't exist before
- Cognitive load for users could spike if we announce too aggressively
I'm not sure this is the right move, but I understand why it exists. The web platform keeps adding power because developers keep asking for it. The asking part is valid. The using-it-responsibly part is where things get murky.
The Temptation vs. The Reality
Here's what I think will happen in production codebases: someone will use ariaNotify() to announce literally everything. A user types in a search field. Announcement. Autocomplete loads. Announcement. Results filter. Announcement. By the time they've actually clicked something, the screen reader has talked so much that it's just noise.
I've seen this with analytics tracking before. Not exactly the same, but the pattern repeats. You gain the ability to instrument something granularly, so you do, and suddenly you're drowning in data that doesn't help. Same energy, different API.
What makes this harder is that accessibility isn't always a competitive priority in fast-moving teams. If you're shipping features weekly, the temptation to over-announce—to make sure nothing gets missed—is intense. I'm not sure developers will have the discipline to use restraint here.
Where It Actually Shines
That said, there are genuine use cases where this is cleaner than what came before. Financial alerts. Security notifications. Confirmations that require immediate attention. According to WebAIM's 2023 screen reader survey, about 14% of internet users rely on these tools daily. Those 14% deserve announcements that aren't buried in a soup of polite or assertive live regions that may or may not fire depending on timing.
Real-time collaboration tools, too. When someone else joins a meeting or edits a shared document, you want to announce it immediately and precisely. The old approach—dumping content into a live region and hoping—feels fragile in comparison.
But the moment you make something this straightforward, you create an expectation that it'll be used everywhere, and that's where the risk lives.
What We Actually Need to Figure Out
The WAI-ARIA spec doesn't tell you how many announcements are too many. There's no guidance on whether rapid-fire notifications help or harm comprehension. No real data yet on how users feel about applications that suddenly have opinions about what deserves narration. Testing with actual screen reader users—not automated checkers, actual people using JAWS or NVDA—will answer some of these questions, but I suspect many teams will skip that step.
I'm planning to test ariaNotify() in a small project before rolling it into production work. Something low-stakes. Something where I can watch how it actually feels in context, not just in documentation.
The power is there. The responsibility is too. Whether we handle it well—
