Published: Feb. 26, 2017

Dynamic content is an important source of information and functionality. In this case, dynamic content refers to content on a page that changes without the page reloading. When a page is static, the only way for new content to appear is to pull up a new page. Dynamic content, on the other hand, makes the content change based on parameters. For example, a weather page might change based on the location a user puts in and the current time, or the homepage to a newspaper might update based on significant events.

When presenting content, this information will be useful in explaining potential accessibility issues that could come up in widgets you choose or that might be built into the framework of the platform you are using. If you are mostly using pre-made tools, it is likely that you will not have much control over the accessibility of each tool. The goal of this article is to explain why a tool might present issues, mainly focus on the big picture. If you are a developer, our goal is to provide you with some idea about potential problems and issues to keep in mind and to get you started on finding ways to solve the problems. The following does not provide information on how to handle each issue, it explains the issues and their impact.

The accessibility of dynamic content has improved over the past several years, but there are still complications. There are many ways to create dynamic content, and thus there are many ways to make it both inaccessible and accessible. There are ways to improve accessibility within tools such as JavaScript, as well as tools developed specifically for accessibility such as WAI-ARIA. Once you have done your best to make your dynamic content accessible, it is important to test it with multiple screen readers and browsers, because the differences in how they each interact will make it hard to predict reliably what will work. Below are some examples of the more common issues for dynamic content with screen readers and magnifiers.

Awareness of Updates

Screen Readers

It is important to make sure a screen reader is aware of dynamic content that changes after the page loads. A screen reader’s view of a page comes from the virtual buffer it creates based on what is present when the page loads. The content in the virtual buffer does not necessarily change every time the page changes, so the event causing the change needs to trigger the screen reader to update its view of the page. Here is an example of content that does not update for the screen reader.

Blind and Low Vision Users

In the same way that it is important to make sure the assistive technology is aware of changing content, it is also important to make sure the user is aware. If there is no audible cue to changes, the new information is essentially invisible to the blind or low vision user until they find it; a low vision user might not see the change in the part of the screen they are looking at when the change occurs, and a blind user will only find it when they navigate to it. Here is an example of a pop-up box that the screen reader does not detect. One way to help the user to find it is by placing the new content in the document object model (DOM) just after the element that caused the change. Because a screen reader navigates the page in a linear manner, reading through the code top to bottom, the new content comes next in the flow of the document for them. A screen magnifier user is most likely to capture the change in the magnified portion of the screen if the change is also physically close by in the layout of the page. Furthermore, if a section of the page has updating content, providing a way for a screen reader and low vision user to quickly navigate to the section makes it easier to stay aware of the new content. Elements such as headings and landmarks often provide a user with an efficient way to navigate to a particular part of the page.


Web Accessibility Initiative Accessible Rich Internet Applications (WAI-ARIA) defines a way for various parts of pages and applications to provide more information to assistive technologies. For example, ARIA creates a way to make the screen reader aware when information changes on a page, as well as to define the importance of the information by interrupting a user to make them aware of the content. However, when ARIA is used improperly or when the code is incorrect, it can make a page or application less accessible, so it is important to learn to use it correctly and then to test it. In addition, there are other ways to address accessibility from within whatever tools you might be using, and it is best practice to use those as well.

Change of Focus

An unexpected change of focus can be disorienting. Imagine if you went to sleep in your bed but woke up on the couch. It is important to avoid unexpected changes in focus and provide programmatic information—information that is available to assistive technology—when a change of focus occurs. Change of focus should not occur when a user is arrow keying or using another shortcut to read the page, although it is reasonable to expect a change of focus after an action such as hitting enter or tabbing. A visible change of focus does not guarantee assistive technology will be aware of it, however, so there must be a programmatic change of focus along with the visual change. The one time when it is okay to change focus without the user triggering an event is when critical events occur such as an alert appearing for a session about to time out; it allows the user to respond in a timely manner.


JavaScript Jump Menus

As a user navigates through the menu options in a JavaScript jump menu, each menu option is selected and activated. Some screen readers in some browsers can ignore the behavior (e.g. Firefox disables JavaScript jump menus) but it is problematic when they do not ignore it. When a menu item is activated, page content changes. A screen reader user has to navigate through the content in order to know what is there. In addition, the user’s cursor frequently winds up at the top of the page, outside of the menu, or it stops reading and the user has to try various workarounds to get it to the correct spot again.

Appearing Form Fields

Some form fields appear after a user selects an option in a previous form field, and there can be a delay between when the user navigates to the next field and when the screen reader becomes aware of the field. Many screen reader users will tab from field to field in order to expedite the process of filling out forms, and they wind up navigating past new fields. It is important to make sure the screen reader receives a trigger to refresh before the user leaves the field that caused the change. In addition, an audible cue when the new field appears can be helpful. The screen reader can provide the cue, but it needs programmatic information to know something has happened.

User Control

It is important for a user to have control over changes occurring on a page. For example, a screen reader may read captions out loud in some cases, while a video is playing. The user should be able to pause, stop, hide, or set the frequency in changes. 

Change of Elements

There should be textual information about change in state of elements. For example, if a check box is toggled or a button is disabled, the screen reader needs to be able to communicate the current status of the element.


More options for designing content offers an opportunity to deliver a wider variety of materials to more people. At the same time, if developers are not mindful in how they design, new options can also create new barriers. If there is a simple way to achieve a desired effect, stick with the simplest option. If there is a better way to perform a task or present information, keep in mind screen reader and magnifier technology and how it operates.