Accessibility scans process dynamic content by loading a page in a headless browser, waiting for scripts to execute, and then evaluating the rendered HTML, CSS, and ARIA against WCAG success criteria. The quality of that evaluation depends on whether the scanner waits long enough for content to appear, whether it can reach states behind user interaction, and whether the dynamic elements expose proper semantics once rendered. Scans capture roughly 25% of accessibility issues, and dynamic content is one of the areas where that limit shows most clearly.
| Aspect | What Happens |
|---|---|
| Rendering | The scanner loads the page in a headless browser and runs scripts before evaluation. |
| Wait conditions | Scanners wait for network idle, DOM events, or fixed timeouts before snapshotting the page. |
| User states | Content behind clicks, hovers, form input, or authentication is not reached without scripted steps. |
| Coverage limit | Scans flag about 25% of issues. Dynamic interactions often fall into the remaining 75%. |
What Counts as Dynamic Content
Dynamic content is anything generated, modified, or revealed by JavaScript after the initial HTML loads. This includes single-page applications, infinite scroll feeds, modal dialogs, dropdown menus, tabs, accordions, live regions, toast notifications, and content loaded through API calls.
From a scanning perspective, the question is whether the dynamic element is present in the DOM at the moment the scanner takes its snapshot. If it is, the scanner can evaluate its semantics. If it is not, the element is invisible to the scan.
How Scanners Render the Page
Modern accessibility scanners use a headless browser, typically a Chromium variant, to load the target URL. The browser executes JavaScript the same way a regular browser does, building the DOM as scripts run.
The scanner then waits for a signal that the page is ready. Common wait conditions include the load event, network idle (no requests for a set interval), a custom DOM event, or a hard timeout. Once the wait condition is met, the scanner queries the rendered DOM and runs its rules against the elements it identifies.
Content that loads after this snapshot, such as a notification that appears thirty seconds later or a section that renders only when the user scrolls, will not be evaluated unless the scanner is configured to capture it.
Where Scans Reach Their Limit
Dynamic content exposes the boundary between what scans can evaluate and what requires a human evaluator. The most common areas where scans fall short include:
- Interaction-gated content: Modals, dropdowns, and menus that only render after a click or keypress are not opened by a default scan.
- State changes: Whether a button correctly updates aria-expanded, whether a tab panel announces its selection, and whether focus moves appropriately after an action.
- Live regions: Scanners can detect that an aria-live attribute exists, but cannot judge whether announcements are timely, accurate, or appropriate for the user context.
- Authenticated views: Pages behind login require an authenticated session, which a default scan does not have.
- Time-based behavior: Auto-advancing carousels, session timeouts, and animations that affect usability cannot be evaluated by static rule checks.
Techniques That Extend Scan Coverage
Scanners can be configured to cover some dynamic content through scripted interactions, longer wait conditions, and authenticated session capture. A browser extension running inside an active session can scan logged-in pages. Custom scripts can click through navigation, open dialogs, and submit forms before the scan runs.
Scheduled monitoring helps catch content that changes between visits. Running scans on a recurring schedule surfaces regressions introduced by deployments or content updates, even if the dynamic behavior itself is not fully evaluated.
Where Manual Evaluation Takes Over
The 75% of issues scans cannot detect lives largely in interaction, context, and meaning. A manual audit by an accessibility evaluator covers screen reader testing across NVDA, JAWS, and VoiceOver, keyboard testing through every interactive flow, and judgment calls about whether dynamic announcements actually communicate the right information to assistive technology users.
Scans address the rendered output. Manual evaluation addresses the experience of using that output.
Dynamic content is where the two methods most clearly complement each other. The scan identifies the structural and attribute-level issues it can see in the rendered DOM. The audit identifies what happens when a real person interacts with the application across keyboard, screen reader, and visual contexts.