React for accessible public services

Public services have a higher accessibility bar than commercial sites. The DDA in Australia and the Equality Act in the UK both put statutory weight behind WCAG 2.1 AA compliance. So when single-page apps (SPAs) get blamed for accessibility regressions, public-sector teams sometimes reach the wrong conclusion: stop using React. We think that conclusion is wrong, and we keep building accessible React apps.

Here's what makes the difference.

Server-side rendering is non-optional

Client-only React (where the user sees a white page until the JS bundle loads) is a regression for accessibility, performance, and SEO. We don't ship it. Every React build we do is server-rendered (in our case via Volto, which is React + Plone with SSR). The first byte the browser receives is semantic HTML; React then hydrates and takes over.

That single decision solves the largest single complaint people have with SPAs: screen readers and search engines see real content from the first request, not after a JS bundle downloads.

Use the HTML the platform gives you

React's culture of "everything is a div" is the second largest accessibility problem. We enforce semantic HTML in our component library — buttons are <button>, navigation is <nav>, headings have correct levels, form fields have labels associated correctly. axe-core runs in CI on every PR; serious or critical violations fail the build.

This isn't sophisticated. It's just discipline. The framework permits both, and most teams pick the unprincipled side.

Focus management is the hard part

The genuinely-hard accessibility problem in any SPA is keyboard focus. When the route changes, where does focus land? When a modal closes, where does it return to? When a list item is removed, where does focus go next? React doesn't solve this for you; the developer has to think about it.

Our patterns: programmatically move focus to the new page's h1 on route changes; restore focus to the trigger element on modal close; use roving-tabindex patterns for lists and grids. We've codified these in a small in-house focus-management hook so the team doesn't have to reinvent each time.

Don't fight the OS

Respect prefers-reduced-motion. Respect prefers-color-scheme. Respect user font-size settings. Use system focus indicators rather than CSS-overriding them invisibly. Most accessibility regressions we audit are caused by designers fighting the operating system.

Test with real assistive tech

Lighthouse and axe-core catch maybe 70% of accessibility issues. The rest you find by using the site with VoiceOver, NVDA, or JAWS. We do this manually on every release. It's not glamorous but the cost is low and the regression-catch rate is the highest of anything we do.

Why we keep picking React

Despite all that, React is still the right choice for most public-sector SPAs we build, for the unsexy reason that the talent pool is the largest of any modern frontend framework. Government clients can recruit React maintainers in years 3, 5, 10 of a project. They can't hire Svelte people that easily.

Used the way described above, React is no less accessible than server-rendered Django. Used carelessly, it's worse. Pick teams who know the difference.