UI updates are typically obvious to sighted users, who can immediately perceive changes on the screen through visual cues. However, screen reader users rely entirely on programmatic announcements, and without intentional coding many dynamic updates are invisible to them. With insufficient screen reader testing, these flaws are easily overlooked, and most accessibility audits I have conducted include remarks on this issue.

A search function example

An example would be a search function, where typing into a text field results in search hits appearing below. A sighted user can see new results appearing in real time, but a screen reader user receives no indication unless the interface explicitly informs them. In this case, a concise status message such as “28 results found for [search term]” or “No results found” is essential. Note that the status message in this case should be a description of what happened, rather than the full search result.

How to implement

To ensure this kind of feedback is accessible, developers should use ARIA live regions. A well-implemented live region allows screen readers to announce changes without interrupting the user’s current focus or interaction. This preserves usability and avoids frustration caused by unexpected focus shifts. A typical pattern involves an empty container marked with aria-live=”polite” or aria-live=”assertive”, which is updated with status text when updates occur.

In most cases, the status message should be visually presented so all users benefit from the feedback. However, there are valid reasons to make some messages visually hidden, for instance, when the result is already apparent to sighted users. In such cases, the screen reader version can differ from or supplement the visual message, using the aria-label or aria-describedby attributes, or by injecting screen reader-only text using .sr-only CSS classes.

Find below a typical implementation of the .sr-only class, which makes the message invisible while still being announced by a screen reader. Note that other common ways of hiding elements, display: none; and visibility: hidden;, will hide the content from screen readers also, which is why .sr-only is needed.

.sr-only {
  position: absolute;
  left: -9999px;
  width: 1px;
  height: 1px;
  overflow: hidden;
}

Some dos and don’ts on status messages:

• Do keep status messages concise!
• Do test with different screen readers, as interpretations can differ.
• Don’t shift focus to the status message.
• Do use role=”status” as a shortcut for polite announcements.
• Do use aria-atomic=”true” when you want the entire message announced and not just the change.
• Don’t use aria-live=”assertive” unless the message is critical.
• Don’t overuse status messages as they interrupt the flow of the user’s intended usage.

Relevant WCAG criteria

The Web Content Accessibility Guidelines have several relevant criteria, the primary ones from Principle 4: Robust:

4.1.3 Status Messages (AA)
In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

4.1.2 Name, Role, Value (A)
For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

A special note on SPA – Single Page Applications

Single Page Applications are applications which update their content dynamically rather than through traditional page loads. While there are many benefits of coding applications in this way, such as a smooth visual experience, these applications need extra caution to ensure accessibility.

Some things that need to be handled explicitly in a SPA:

• Announce when the user navigates to a new page
• Update the page title
• Manage focus so it behaves like the user expects