Making dynamic content accessible does not mean announcing everything that changes

Modern SaaS products are designed to keep users informed in real time.

For one enterprise collaboration and workflow SaaS client, that meant message updates, task status changes, dashboard refreshes, push notifications, and AI-generated responses all happening within the same platform. These features were meant to make the product feel responsive and collaborative.

But for users relying on screen readers, the experience quickly became overwhelming.

Instead of making it easier to understand what had changed, the platform was announcing too much, too often - sometimes at exactly the wrong moment. There were simply too many announcements competing for the user's attention.

The Challenge

The platform brought several real-time experiences together in one place. Teams could collaborate through messaging, monitor activity through dashboards, receive status notifications, and use an AI assistant to summarize information and generate responses.

Visually, these updates were relatively easy to process. A new message appeared in the chat. A notification badge increased. A chart refreshed. A task changed color. An AI response streamed onto the screen. Users could glance at the interface and decide what needed their attention.

Screen reader users did not always have that same level of control.

Some updates were announced immediately while users were already reading a message or completing another task. Others triggered repeated announcements as information continued to change. In some areas, users heard updated values without enough context to know which metric, task, or conversation had changed.

The platform was technically communicating these updates, but the volume and timing of the announcements made the experience harder to follow.

We found that announcing every change was creating more confusion than clarity. The platform needed to be more selective about what it surfaced to screen reader users, and when.

The Roadblocks

Several issues stood out during testing.

• New chat messages were announced immediately, even when users were interacting elsewhere on the page.
• Multiple notifications appearing close together created repeated screen reader interruptions.
• Dashboard values that refreshed automatically could be announced every time the data changed.
• Users sometimes heard a number or status without enough context to understand which metric, task, or conversation it belonged to.
• Loading, processing, completion, and success states sometimes generated multiple announcements for a single action.
• New items added to activity feeds were announced even when they were not relevant to the user's current task.
• Some critical updates and routine updates were treated with the same level of urgency.

During testing, this often meant that a user trying to complete one task had to listen through updates from several other parts of the platform before getting back to what they were doing.

The challenge was to get important information to the user without turning every change in the application into an interruption.

Why It Mattered

The problem became clearer when we tested these updates together as part of the actual platform experience.

A user could be reading a message while a dashboard value refreshed, a task status changed, and another notification arrived. Visually, these changes appeared in different parts of the interface and could be noticed or ignored depending on what the user was doing.

For a screen reader user, several of those changes could instead arrive as consecutive announcements.

That meant someone who was already focused on reading a message or completing a task could suddenly have unrelated updates inserted into that experience. By the time those announcements finished, the user then had to work out where they had been and continue from there.

The issue became more noticeable because this platform had several systems updating at the same time. The messaging, dashboard, notification, activity, and AI experiences were all useful on their own, but together they created far more screen reader activity than the user actually needed.

What was intended to keep users informed was making it harder for some of them to stay focused on the work they had already chosen to do.

How We Approached It

For every update or change, we started by asking one question: Does the user need to know about this change right now?

We reviewed the platform's live updates based on three factors:

Importance. Timing. Context.

For each update, we looked at:

• Does this information need to interrupt the user?
• Can it wait until the user chooses to review it?
• Does the announcement provide enough context on its own?
• Is this a new event, or simply another stage of the same event?
• How often could this information change?
• What happens when several updates arrive together?
• Can users return to the information later?
• Does focus remain where the user expects it to remain?

We also tested complete workflows rather than reviewing each component in isolation.

For example:

Write message → Receive new message → AI assistant generates response → Task status changes → Notification appears

This helped us understand what users actually experienced when several dynamic features were active at the same time, rather than treating each announcement as a separate accessibility issue.

At the implementation level, we also reviewed how the platform was using ARIA live regions. For dynamic updates that qualified as status messages, WCAG 4.1.3 requires the information to be programmatically determinable so assistive technologies can present it without moving focus. 

We reviewed whether aria-live, role="status", or role="alert" was appropriate for each type of message - and whether an automatic announcement was needed at all. Routine updates could be announced politely or left for users to review when ready, while assertive announcements were reserved for information that genuinely required immediate attention.

The goal was to make sure the right information was announced at the right time.

What Changed

The team introduced a more deliberate approach to live updates.

• Routine updates were no longer automatically announced when users did not need to respond immediately.
• Important announcements were prioritized so critical information was less likely to compete with lower-value updates.
• Multiple related updates were consolidated where possible instead of generating several separate announcements.
• Users were given clearer ways to review updated information when they were ready.
• Announcements included enough context to explain what changed rather than reading isolated values or status labels.
• Chat notifications were adjusted so incoming activity did not constantly interrupt users working elsewhere in the product.
• Focus remained on the user's current task when new content appeared unless moving focus was necessary for completing an action.
• AI responses were handled differently so screen readers were not expected to follow every fragment of streaming text as it appeared.

For the AI assistant in particular, the goal was to keep the conversation feeling responsive without making users listen to a sentence being reconstructed word by word as the response streamed in.

The platform still provided the same real-time information. It simply became more deliberate about when that information needed the user's immediate attention.

What Changed for Users and the Business

After the live-update behavior was revised, the client saw improvements across several key workflows.

We compared the four weeks before remediation with the four weeks after deployment, using product analytics to measure workflow abandonment and completion, and tagged support tickets to track accessibility issues related to notifications and dynamic content.

Across those periods:

• 21% fewer users abandoned workflows involving live dashboard updates
• 24% improvement in successful completion of collaboration tasks among assistive technology users
• 33% fewer accessibility-related support requests connected to notifications and dynamic content
• 8% improvement in completion of workflows involving the AI assistant

The smaller 8% improvement in AI-assisted workflows reflected that the remediation primarily improved how streaming responses were announced, while other factors continued to influence whether users completed the workflow.

More importantly, users were able to stay focused on the task they had chosen instead of having unrelated activity repeatedly interrupt them.

For the client, the changes did not require removing the real-time features that made the platform useful. They made those features work together more effectively for users relying on assistive technology.

What We Learned

Making dynamic content accessible does not mean announcing everything that changes.

That was particularly clear on this platform, where messaging, dashboards, notifications, activity updates, and AI responses could all be active within the same session.

Sometimes an update needed to be announced immediately. Sometimes it needed better context. And sometimes it was more useful to let the user review the change when they were ready.

For this platform, reducing unnecessary screen reader noise made the real-time experience more useful. Users could stay focused, and the features designed to keep teams informed could do that without constantly getting in the user's way.