Accessibility for SaaS and Single-Page Apps

Web apps built with React, Vue, Svelte, and friends are powerful — and they introduce accessibility problems that static sites don't have. Content appears and disappears without a page load, "pages" change without a real navigation, and a lot of the UI is custom components rather than native HTML. The same WCAG 2.2 AA standard applies; you just have to handle the dynamic parts deliberately. (General information, not legal advice.)

1. Manage focus on view/route changes

In a single-page app, clicking a link swaps the view but doesn't reload the page — so screen-reader and keyboard users get no signal that anything changed, and focus is left wherever it was. On each route change, move focus to a sensible place (the new page's heading or main region) and update the document title. Without this, navigation is deeply confusing for assistive-tech users.

2. Announce dynamic updates with live regions

Toasts, "saved," validation messages, search results that update as you type, loading states — sighted users see these; screen-reader users won't unless you use an ARIA live region (aria-live="polite" for most, assertive for urgent). Don't move focus to a toast; announce it via the live region instead.

3. Make modals and overlays accessible

When a dialog opens it must:

Move focus into the dialog and trap focus while open.
Close on Esc and return focus to the element that opened it.
Expose the right semantics (role="dialog", aria-modal="true", a label).
Prevent interaction with (and ideally hide from screen readers) the background content.

Same goes for menus, comboboxes, tooltips, and drawers.

4. Custom widgets need keyboard + name/role/value

A <div> styled as a button isn't a button. Custom dropdowns, tabs, sliders, toggles, and tree views need full keyboard support (arrow keys, Enter/Space, Esc) and correct name, role, and value via ARIA so assistive tech understands them. The ARIA Authoring Practices Guide documents the expected keyboard behavior for each pattern.

5. Don't break what HTML gives you free

The most reliable accessibility win in an app is to use native elements — <button>, <a>, <input>, <select>, <dialog> — which come with keyboard, focus, and semantics built in. Reach for ARIA only to fill gaps, and remember the first rule of ARIA: don't use ARIA if a native element will do.

6. Test the dynamic states, not just the initial render

A scan of the first paint misses most app bugs. Test with content loaded, menus open, modals open, and errors showing. Tab through each state, try it with a screen reader, and watch what gets announced. Run an automated scan on representative states to clear the mechanical issues — Scan your site free with WCAGwise on a given view to find them and where they are — then do the manual keyboard/screen-reader pass that the dynamic behavior really needs. WCAGwise is an audit aid, not a legal guarantee.

Accessibility for SaaS and single-page apps