Making dynamic Content accessible

Dynamic changes on websites can improve usability and User Experience (UX) – especially in single-page applications (SPAs). However, they present developers with the challenge of preparing these changes in such a way that they are correctly processed by assistive technologies like screen readers.

Basically, dynamic changes can be divided into two types:

  1. Informational changes: The element passes information to the screen reader without moving the user's keyboard focus.
  2. Focus-changing changes: The keyboard focus is specifically shifted to the new or changed element.

Basic rule: A shift or catching of focus should only take place if it is strictly necessary.

1. Overlaying Elements and Menus

Modal Dialogs (Modals)

A modal acts as an overlay over the content of the web page (e.g., a cookie banner). The background is visually grayed out and disabled for interaction.

  • Accessible implementation: As long as the modal is open, focus must remain trapped within the modal. Interaction with the grayed-out background must not be possible.
  • Practical problem: Many implementations are flawed because users can continue to interact with the background or do not notice that the modal has opened at all.

Pop-Outs

Pop-outs are similar to modals, but the background remains visible.

  • Focus management: If focus moves into the expanding area, the screen reader must be explicitly informed about the context change. Blind users must be able to understand that an area has opened and how to leave it again.
  • Closing: When closing the pop-out, focus must automatically be reset to the trigger (the initiating element).

Flyouts and Submenus

Flyouts are collapsible menu structures.

  • Status communication: The state (expanded / collapsed) must be communicated to the assistive technology.
  • Keyboard navigation: It is advisable to give the user the option to close the submenu at any time using the Esc key and return to the trigger element.

Many argue that focus should remain in the submenu. In single-page applications, this makes sense from my point of view, as it corresponds to the behavior in desktop apps. For flyouts in website navigations, I do not see this as essential, as long as the menu does not automatically close as soon as you leave the menu, and it is clear to the screen reader user that they are leaving or entering the menu.

2. Notifications and Status Messages

Form Validation and Error Messages

Dynamic error or success messages in forms are usually not interactive.

  • Focus: Focus should not be moved.
  • ARIA attributes: The message belongs in an aria-live region. Additionally, the corresponding input field should be linked to the ID of the error message via aria-describedby.

Toast Messages / Alerts

Toast messages usually pop up briefly at the edge of the screen.

  • No focus shift: Focus should never jump briefly to the pop-up and back, as this is extremely confusing.
  • Interactive toasts (e.g., "Undo"): If toasts contain buttons, focus should still not necessarily be shifted. Instead, providing a global keyboard shortcut or placement in the DOM that allows quick access is recommended (e.g., at the beginning of the content area).

3. Dynamic Content Changes and Forms

  • Changes after/below the trigger: If form fields change below a user input (e.g., additional fields depending on the selection of marital status), a direct announcement is not always necessary, as the user will automatically encounter them when navigating further.
  • Changes before/above the trigger: If an area changes above the current position (e.g., a dynamic number of results above a search field), this information must be announced.
  • Auto-suggest / Suggestion lists: For search fields with a dynamic suggestion list, the screen reader must report that suggestions are available and how they can be reached (e.g., using the arrow keys).

4. Progress and Loading Indicators

Progress Bars

  • Interval selection: For fast progress indicators (e.g., a loading bar from 0–100% within a few seconds), not every percentage change should be announced. This leads to information overload and makes the application unusable.
  • aria-live modes:
  • polite (recommended): The screen reader waits until the current speech output is finished before reading the update.
  • assertive: Immediately interrupts the current speech output. This should be reserved only for time-critical emergencies (e.g., "Automatic logout in 10 seconds").

Loading Indicators (Spinners)

If a loading process blocks the entire page or an area, you can proceed similarly to a modal: The ARIA attribute communicates that the application is working, while focus is kept inside the loading indicator during the loading process.

5. Complex UI Patterns and Modern Web Applications

Infinite Scroll

On platforms with infinite scrolling (e.g., feed content in social media), the loading of new content must be communicated. Otherwise, screen reader users will not understand why they cannot reach subsequent page areas (such as a right sidebar) while scrolling/navigating.

Standard HTML Components (Accordions, Tabs, Selects)

If you build menus, accordions, or tab panel structures using native HTML and standard ARIA attributes, the effort remains low:

  • Communicate state via aria-expanded / aria-selected.
  • Hide inactive content from screen readers using hidden or CSS properties as long as the tab/accordion is closed.

Dynamic URL Changes Without Reloading (Single Page Applications)

If the URL is adjusted dynamically (e.g., when flipping through media content) without an actual page reload occurring, the screen reader focus remains in place.

  • Solution: The document.title can be updated via JavaScript. Screen readers register this update and read out the new page title, providing clear orientation for the user.

More on accessible Components