A scan can detect issues on a single page app, but only when the scanner is configured to wait for JavaScript-rendered content and to capture each application state. Default scan settings designed for static HTML pages will miss most of what a single page app contains. Even with proper configuration, scans of single page apps surface only about 25% of accessibility issues, the same coverage limit that applies to any automated evaluation.
| Key Point | What It Means |
|---|---|
| Scans Work on SPAs | Modern scanners can evaluate JavaScript-rendered content when configured to wait for the DOM to fully load. |
| Each State Counts as a Page | A single URL in a single page app can contain dozens of distinct views that each require separate evaluation. |
| Authenticated Views Need Setup | Scanning logged-in states requires a browser extension or session-aware scanner running inside an active session. |
| Coverage Stays at 25% | Scans on single page apps detect the same proportion of accessibility issues as scans on static sites. The other 75% requires a manual audit. |
How Single Page Apps Differ From Traditional Sites
A traditional website serves a new HTML document for each URL. A single page app loads one HTML shell, then uses JavaScript to render content, swap views, and update the DOM as the user interacts with the interface.
This matters for scanning because older scanners evaluate the initial HTML response from the server. On a single page app, that initial response is often close to empty. The actual content, including headings, links, form fields, and ARIA attributes, only appears after JavaScript executes in the browser.
What a Scan Can Detect on a Single Page App
A scanner that runs inside a real browser environment, including headless Chrome or a browser extension, can evaluate the rendered DOM. Once the page is fully rendered, the scan checks the same WCAG success criteria it would check on any other page. This includes missing alternative text, form labels, heading structure, link names, ARIA usage, and document language.
Browser-based scanners and API-based scanners that wait for JavaScript completion produce results comparable to what they would produce on a server-rendered page. The detection logic does not change. What changes is the timing and the configuration needed to capture the rendered output.
What Scans Miss on Single Page Apps
The 25% coverage limit applies regardless of whether the page is static or dynamic. Scans on single page apps still cannot evaluate keyboard operability of custom widgets, screen reader announcements during view transitions, focus management when content updates, or whether ARIA live regions actually communicate state changes to assistive technology.
Single page apps introduce specific patterns that scans address poorly. Route changes that update the URL without a page reload often leave focus stranded on the previous element. Modal dialogs built with custom components may not trap focus correctly. None of these behaviors show up in a scan report. They require screen reader testing and keyboard testing performed by an accessibility professional.
Configuring a Scan for a Single Page App
Three configuration points determine whether a scan returns useful results on a single page app:
- Wait conditions: The scanner must wait for the DOM to stabilize after JavaScript execution, not evaluate the initial HTML response.
- State coverage: Each meaningful view, including modals, multi-step forms, and route changes, needs to be scanned as a separate state, even when the URL does not change.
- Authenticated access: Views behind a login require a browser extension running inside an active session or a scanner that supports credentialed access.
Without these in place, a scan of a single page app may return a near-empty report that suggests the application has no issues. The application has issues. The scan did not see the content.
Where Scans Fit in a Single Page App Evaluation
Scans are most useful on single page apps as part of ongoing monitoring. Once an application has been audited and remediated, scheduled scans flag regressions in areas the scanner can evaluate, such as missing labels on newly added form fields. This monitoring layer catches the 25% of issues that automated checks can identify, while a manual audit identifies the remaining 75% that scans cannot reach.
Single page apps benefit more from this combination than traditional sites because their dynamic nature creates more opportunities for accessibility regressions between releases.