Accessibility isn’t a feature you can turn off

I was in a meeting recently where a product owner asked why we couldn’t just add dynamic searching to a postcode lookup. Select some checkboxes, repopulate the results on the page, no reload. It would be quicker. More modern. “Why are we making people go through two or three screens when JavaScript could just do it on one page?”

It’s a fair question on the surface. I’ve had it asked enough times that I’ve stopped being surprised by it.

The answer is always the same: because we build for everyone, not just the people in this room.

I work in the public sector. My applications serve members of the public, and we are legally required to meet WCAG accessibility standards. This isn’t a guideline we aspire to. It’s a standard we are actively audited against by the Government Digital Service, and we can be fined for non-compliance.

Accessibility isn’t a phase we add at the end. It’s not a ticket we pick up before launch. It’s the foundation.

My team follows progressive enhancement formally. That means our applications must work with HTML alone. No CSS. No JavaScript. Just the markup. If a user’s browser fails to load a stylesheet or a script doesn’t execute, the application still functions.

That sounds extreme to people who’ve never had to think about it. But it’s the baseline. Everything else, the styling, the interactivity, the polish, is enhancement on top of something that already works.

The postcode search conversation is a good example of where this gets challenged. Dynamic filtering with AJAX, checkboxes repopulating results without a page reload. That works perfectly for a sighted user on a modern browser with JavaScript enabled and no assistive technology.

But that’s not the only user.

When you dynamically update a page, you have to communicate that change to everyone. A screen reader doesn’t know that results just changed unless you tell it, explicitly, through ARIA live regions and careful focus management. Keyboard users need to know where they are after content shifts beneath them. Users on slow connections need the page to remain functional while scripts are still loading, or if they never load at all.

A multi-page flow handles this naturally. Each page is a complete, self-contained document. The browser announces the new page. Focus resets predictably. There’s no ambiguity about what changed, because everything changed.

Is it more clicks? Yes. Is it less technically exciting? Absolutely. But it works for the widest range of people, and that’s the metric that matters.

The pushback almost always comes from the same place.

That statement arrives without data. Nobody has audited every browser configuration across an organisation of several thousand people. Nobody has confirmed that every single user has no accessibility needs. It’s an assumption dressed up as a fact, and it’s used to justify shortcuts.

My response is always the same: prove it. Prove to me that every user in this organisation has JavaScript enabled. Prove to me that nobody in a workforce of thousands has a visual impairment, a motor disability, or a cognitive condition that affects how they interact with software.

Nobody can. Because it’s not true.

And even if it were true today, it wouldn’t be true tomorrow. Accessibility isn’t about the users you know about. It’s about the ones you don’t.

My team has been through three GDS accessibility audits across three different products, plus a revisit audit two years later on one of them. We are actively monitored.

On several products, the audits caught things. Automated testing flagged issues we hadn’t spotted: contrast ratios, missing labels, heading hierarchy problems. We fixed them. That’s the process working as intended.

We’ve also pushed back on a couple of findings where we believed the automated tooling was flagging false positives. GDS automated testing doesn’t include human review, so there are cases where the tool flags something that is technically non-compliant but functionally accessible in context.

The point is: these audits are real. The consequences are real. If we’d built everything with heavy client-side JavaScript and worried about accessibility later, those audits would have been a very different conversation.

This gets misunderstood, so I want to be clear: we’re not anti-JavaScript. A lot of our applications run on Node.js. Server-side JavaScript is a core part of our stack.

The distinction, and it’s one we’ve had to write internal articles about because it gets confused so often, is between server-side and client-side JavaScript.

Server-side JavaScript runs on the server, renders HTML, and sends a complete document to the browser. The user doesn’t need JavaScript enabled to interact with that page. Client-side JavaScript runs in the browser and manipulates the page after it’s loaded. If it fails or hasn’t loaded yet, anything that depends on it stops working.

We use client-side JavaScript where it’s genuinely necessary. But those are enhancements, not foundations. They make the application better, not possible.

Within our organisation, we maintain a shared frontend library that adopts accessibility and progressive enhancement principles. We have our own design system, with dedicated sections on progressive enhancement, WCAG compliance, and sustainability, specifically to educate teams on these standards.

We’ve written internal articles on when client-side JavaScript is appropriate and what progressive enhancement actually means in practice. Including, because it comes up often enough, the difference between server-side and client-side JavaScript.

And still, the question keeps coming.

The frustration isn’t really about JavaScript. It’s about the gap between what people think accessibility means and what it actually requires.

Most people think accessibility means adding alt text to images and making sure the colours aren’t too similar. That’s part of it. But the real work is structural. It’s about how information flows, how navigation works, how state changes are communicated, and whether the application makes sense when you strip away everything except the HTML.

I’ve found that the most effective way to shift this understanding is to show, not tell. Open a screen reader. Navigate the application with a keyboard. Turn off CSS and see what’s left. When people hear what a dynamic AJAX update sounds like through a screen reader, which is usually nothing, because nobody added the ARIA attributes, the argument resolves itself.

But you have to keep doing it. Every new stakeholder, every new designer, every new product owner needs to see it. The instinct to reach for client-side JavaScript isn’t malicious. It comes from a genuine desire to make things smoother and faster. The intent is good. It just needs redirecting.

It would be easier to build everything with React and hope for the best. Nobody would notice, until the audit, or until a user with a disability couldn’t complete a form, or until a browser extension blocked a script and the entire application stopped working.

Accessibility isn’t a feature you can turn off when it’s inconvenient. If that means three screens instead of one, then it means three screens instead of one.

Because the alternative is an application that works brilliantly for most people and doesn’t work at all for some. And in the public sector, “some” isn’t an acceptable number.