SPA Accessibility Checklist

Single page applications introduce unique accessibility challenges around routing, focus management, and dynamic content updates. This checklist helps you ensure your SPA works for everyone, including screen reader and keyboard-only users. Your progress is saved automatically.

Interactive Reference

0 of 24 items complete

Route Changes

Route changes are announced to screen readers Use an aria-live region or focus management to announce navigation to screen reader users. Without this, route changes are silent. SPA Accessibility guide
Document title updates on every route change Update document.title to reflect the current page. Screen readers announce the title on page load, and it appears in browser tabs and history.
Browser back/forward buttons work correctly Ensure the History API is used properly so back and forward navigation works and page changes are announced to assistive technology.
URL updates on navigation for bookmarking and sharing Each view should have a unique URL so users can bookmark, share, and return to specific content directly.
Deep links load correct content and set appropriate focus Direct URLs (not just the root) must load the correct view and place focus on a meaningful element such as the main heading. Focus Management guide

Focus Management

Focus moves to a meaningful element after route navigation After a route change, move focus to the page heading, main content area, or skip link target so keyboard and screen reader users know where they are. Focus Management guide
Focus is not left on destroyed or removed DOM elements When a view transition removes the currently focused element, focus must be moved to a valid target. Orphaned focus causes screen readers to lose their place.
Modal and dialog focus trapping works correctly Focus must be trapped inside modals and dialogs while they are open, and must not escape to content behind the overlay. Modal pattern
Focus returns to trigger element when closing overlays When a modal, popover, or dropdown is dismissed, focus should return to the button or link that opened it. Modal pattern
Focus is managed when content is dynamically added or removed Expanding an accordion, filtering a list, or loading new content should not disrupt the user's focus position or keyboard navigation flow.

Dynamic Content

Loading states are announced to screen readers Use aria-busy="true" on the loading container or an aria-live region to communicate that content is loading. ARIA guide
Inline error messages are associated with form fields Use aria-describedby to link error messages to the relevant input so screen readers announce the error when the field receives focus.
Notifications use appropriate aria-live politeness Use aria-live="polite" for status messages and aria-live="assertive" for critical errors. Avoid overusing assertive announcements. Toast pattern
Infinite scroll or lazy-loaded content preserves keyboard navigation Dynamically loaded content must not break tab order or trap keyboard focus. Provide an alternative mechanism (e.g., pagination) for accessing all content.
Content changes without user action are announced Real-time updates (live scores, chat messages, stock prices) must use aria-live regions so screen reader users are informed of changes.

Error Handling

404/not-found states are communicated to screen readers When a route does not match, display a clear heading (e.g., "Page not found") and move focus to it so screen reader users understand what happened.
Network errors display accessible error messages with retry actions Show a clear error message when API calls fail and provide a focusable retry button. Announce the error using an aria-live region.
Form validation errors are summarized and linked to fields Display an error summary with links to each invalid field. Move focus to the summary on submission so users can navigate to and fix each error.
Authentication timeouts warn users and offer session extension Before a session expires, display an accessible warning dialog that allows users to extend their session. Ensure the dialog is keyboard operable and announced.

Testing & QA

All routes tested with a screen reader Test every route with at least one screen reader (VoiceOver, NVDA, or JAWS) to verify announcements, focus order, and content structure. SPA Accessibility guide
Full keyboard navigation tested through all routes Navigate the entire application using only the keyboard. Verify that focus is never lost, trapped unexpectedly, or left on removed elements. Keyboard Testing guide
Automated accessibility tests run against all route states Integrate axe-core, Pa11y, or similar tools into your CI pipeline to catch regressions. Test each route in its various states (loading, error, empty, populated).
Dynamic content tested for aria-live region announcements Verify that loading indicators, toast notifications, and real-time updates are announced correctly by screen readers at the appropriate politeness level.
Browser back/forward tested with screen reader Navigate forward through several routes, then use the back button. Verify that each page change is announced and focus is placed correctly.

Frequently asked questions

Why do SPAs need a special accessibility checklist?

SPAs break a lot of default browser behavior — focus state on route changes, page-title updates, screen reader announcements of new content, the back button. Most accessibility failures in modern web apps come from these SPA-specific issues. The SPA Accessibility guide covers each.

How do I handle focus on route change?

After the new view renders, move focus to either: (a) the new page's <h1> (using tabindex="-1" + focus()), or (b) a hidden "You're now on the X page" announcement in a role="status" region. Either resets the user's place in the document. See the Focus Management guide.

Does my SPA's title need to update on navigation?

Yes — document.title must reflect the current page, just like in a multi-page app. Screen readers announce the title on page change. Update it as part of your route change handler. (React Router, Next.js, Vue Router all have helpers; if not, just document.title = '...'.)

What about the back button?

Use history.pushState for in-app navigation so the back button works. Don't hijack it. If you use a state-based pseudo-navigation (like opening a modal), pushing a new history entry lets users back out of the modal naturally.

How do I announce async content updates to screen readers?

Wrap a dedicated container in aria-live="polite" (or role="status"). When async content loads, update the container's text. Screen readers will announce the change. For urgent errors, use role="alert" instead. See the Live Regions guide.

Do React/Vue/Svelte affect any of this?

The semantic HTML, ARIA, and focus management requirements are framework-agnostic. The integration patterns differ — useEffect cleanup for focus traps, framework router APIs for navigation hooks, refs/forwardRef for DOM access. The items in this checklist apply regardless of framework; per-framework guides cover the integration specifics.