Provide notification of dynamic changes to content

Where dynamic content is updated either automatically or in response to a user action, make sure that users are notified of this update in an accessible way.

Make sure that the notification is appropriate to the type and importance of update that has taken place. For example, an update that reports an error or a problem may be considered more important than an update to a newsfeed that is shown as supplementary content to the main page.

  • Identify content that may be updated as a WAI-ARIA live region. Use the aria-live attribute on the container of the content that may be updated or, in special cases, use one of the WAI-ARIA special live region roles.
  • Make users aware of important changes in content. However, do so by clearly identifying critical updates versus information-only updates. Change focus only when an alert is critical to the user's current activity. Otherwise, don't force a focus change and/or interrupt the user's work. This guideline is especially useful to screen reader users and to those with cognitive disabilities.
  • Provide a suitable priority for update notifications. Decide how important it is that a user hears the updated content and whether the screen reader should be interrupted from what it’s currently reading. This will influence what value you give the aria-live attribute.


  • For each piece of dynamically updated content, inspect the underlying code. Is it identified in code as a live region, with a suitable level of priority of notification?
  • Listen to the page with a screen reader. Are notifications made in an accessible way, including making users aware of important changes in content? 


✎ Technique: Status messages

Assistive technology users should be able to detect when important changes occur on a web page, With the use of a status message, information can be provided to the user without changing focus or unnecessarily interrupting their work. The following are the kinds of status messages to provide:

  • success or results of an action
  • waiting state of an application
  • progress of a process
  • existence of errors


✗ Bad example

Omitting the role=status does not allow screen-reader users to detect the presence of new content on a web page.

<div>2 results returned.</div>

✓ Good examples: providing role=status

Example #1 - status message

Use role=status to present status messages. The role=status will allow screenreaders to detect when this information is made available by moving the focus to this content:

<div role="status">2 results returned.</div>

After a user presses a Search button, the page content is updated to include the results of the search, which are displayed in a section below the Search button. The change to content also includes the message "2 results returned" near the top of this new content. This text is given an appropriate role for a status message. A screen reader will announce "Two results returned".

Example of 4.1.3 guideline  Example of 413 guideline

Example #2 - alert message

In the example below, a screen reader can announce a properly implemented status message. This example simulates a product comment form. If the user is idle too long, a message displays warning that the system will log them off. The screen reader announces the new message. In the example below, the user navigates to the comment field and then leaves the cursor idle. This example displays the warning message that will be read immediately by a screen reader.

Screen capture of an accessible alert message

(Source: Knowbility article on status messages)

✎ Technique: Form feedback with live regions

Providing form feedback accessibly helps users submit data more accurately and reduces the chance for error. For learning resources, easy access to feedback supports the learning process; for forms collecting data, good feedback helps to reduce the chance of input errors being made. 

When providing feedback on user input, JavaScript is often employed to print messages to the screen. Users looking at the screen will see the message appear in response to their actions. Screen-reader users who do not have access to visual changes need to be notified of the feedback so they can have an opportunity to read it and act on it.

WAI-ARIA live regions can be used for this. Adding content inside a live region tells assistive technologies to announce the content to the user—without users having to move to that part of the page.


In this example, the user is presented with a multiple choice quiz question: "Who's the biggest selling recording artist?" When they click the "check answer" button, a message provides feedback on their answer. The markup looks like this:

    <legend>Who's the biggest selling recording artist?</legend>
      <label><input type="radio" name="answer" value="michael"> Michael Jackson</label>
      <label><input type="radio" name="answer" value="elvis"> Elvis Presley</label>
      <label><input type="radio" name="answer" value="iggy"> Iggy Pop</label>
      <label><input type="radio" name="answer" value="madonna"> Madonna</label>
  <div aria-live="polite">
  <div class="buttons">
    <button type="button" class="check">check answer</button>
    <button type="submit" disabled>next question</button>

Note the empty <div> with the aria-live="polite" attribute. This is our live region. When we add content inside it (text or HTML elements containing text), screen readers will announce that content.

For instance, if the user activates the "check answer" button without having chosen an answer, the live region will be populated with the message, "Please choose an answer." This message appears to sighted users as a highlighted box, and it’s heard as speech by an assistive-technology user.


If, upon pressing "check answer," the user has the correct answer checked, the message congratulates them. In addition, the "next question" button is enabled (by removing the disabled attribute) and focused.


Using the screen reader NVDA with Firefox, this produces the screen reader speech output, "Elvis is correct! You can go to the next question, next question button." That is, the live region is announced, and then the newly focused element is announced. Three important pieces of information are provided: The user has chosen correctly, they can continue, and the button currently in focus will allow them to continue. Had we used an aria-live value of assertive, the live region's message would have overridden the focus change and "next question button" would not have been announced.

Video: Form feedback with NVDA using a live region


Video: Form feedback with NVDA using a live region


Code editor

An editor is available to try out the preceding live region example. Experiment by removing the live region and try operating it with just the keyboard, with your eyes closed.

See the Pen form feedback with live regions by HUIT - Web, UX and Digital Accessibility Services (@hwpdas) on CodePen.