The Accessibility Problem Isn't Design. It's Engineering.

The European Accessibility Act came into force on 28 June 2025. Teams audited their components, ran Axe, added ARIA attributes, and ticked boxes. Compliance documents were written. Statements were published in footers. And then most of them moved on.

Nine months on, I’m not sure much has.

Accessibility isn’t a design problem with a checklist solution. The specs were written, the components annotated, the guidelines documented. And then engineering shipped something broken anyway. The design was right. The code wasn’t. It’s the same story on almost every team, while the industry pretends the problem is awareness.

It’s about who’s writing the front-end code, and whether they’re qualified to write it.

Somewhere in most organisations there is a designer who cares about accessibility. They annotate their components. They specify focus states, label associations, heading structures. They do the work.

And then engineering builds something else entirely.

Nobody means to. The industry created a skills gap and is now making it worse.

The full-stack engineer has become the default hire. One person, one salary, covering the database, the API, the back-end logic, and the front-end interface. Efficient on paper. Easy to sell in a headcount meeting. Shit for whoever has to use what gets built.

Because front-end is a specialism. Semantic HTML, document structure, keyboard interaction, ARIA, the relationship between visual design and accessible implementation: these aren’t things you absorb by proximity or pick up in an afternoon. They require years of focused attention. They require someone whose job it is to care about them, not someone who gets to them after the back-end is done.

The full-stack engineer doesn’t have that depth. They can’t. They’re stretched across too many concerns, context-switching too frequently, and operating in a discipline they were never trained in. The front-end work gets done last, under time pressure, by someone who doesn’t understand what makes it hard. The result is exactly what you’d expect: div soup where semantic elements should be, heading structures that skip levels or don’t exist, interactive elements with no keyboard support, ARIA attributes cargo-culted from a Stack Overflow answer by someone who had no idea what they were doing.

This is the norm, and the industry built it on purpose to get cheaper, leaner teams.

The audit finds it eventually. But by then, real people have already been excluded.

Then add AI

Copilot doesn’t know your design system. It doesn’t know your component architecture, your token structure, or the accessibility decisions baked into your foundations. It has no context for any of it. What it does have is a vast dataset of code (including a vast dataset of inaccessible code) and the ability to generate confident, plausible-looking output faster than anyone can review it properly.

For an engineer who understands front-end, that’s useful. They can tell when the output is wrong, why, and how to fix it. It makes good engineers faster.

That is not what is happening on most teams.

For an engineer without front-end foundations, Copilot is a way of producing broken code in bulk, with total confidence. The output looks clean. It passes a cursory review conducted by someone with exactly the same blind spots. Nobody in the chain (not the engineer, not the reviewer, not the lead who approved the PR) has the knowledge to see the problem. So it ships. And because it arrived quickly and looked professional, nobody questions it.

This is why it’s worse now. It was always possible for an under-qualified engineer to write inaccessible front-end. But there were limits. It took time. The gaps were sometimes visible. Somebody occasionally noticed.

AI removes all of that. It churns out more broken code, faster, than any engineer could alone. The interface fails a screen reader user. The keyboard trap goes unnoticed. The heading structure is a disaster. And the team that shipped it is proud of how quickly they moved.

Automated accessibility tooling catches around 30 percent of issues, according to research by the UK Government Digital Service. The rest require human judgement: someone with the craft knowledge to find what the tools can’t see. When that person isn’t on the team, the other 70 percent stays broken indefinitely. Copilot won’t find it. Axe won’t find it. A real user will.

The wrong fix

Compliance with the European Accessibility Act is not the same as being accessible. Not even close.

WCAG 2.2 AA is a floor. A low one. It’s a set of technical criteria that can be audited, documented, and signed off by a legal team that has never used a screen reader. It says nothing about whether a disabled person using assistive technology can get through your product with any dignity or independence. You can pass every single checkpoint and still build something that excludes the people it’s supposed to serve.

The checklist mentality produces defensible products, which isn’t the same as accessible ones. A statement in the footer, a report for procurement, something to keep legal quiet until the next audit.

Inclusion asks different questions entirely. “Can someone who relies on a screen reader complete this journey without hitting a wall?” “Does this label make sense in context to someone who can’t see the visual relationship?” “Did we test with a real person, and did we listen to what they told us?”

A tool can’t answer those. Nor can a designer in Figma, or a compliance report. It takes someone who knows front-end well enough to see how the thing behaves on real devices with real assistive technology.

Compliance is what you get when you treat accessibility as a legal problem. Inclusion is what you get when you treat it as an engineering one. The industry has spent years chasing the first and wondering why it never gets the second.

The fix

It starts with the industry being honest about what it has done. It stripped out front-end specialists in favour of cheaper generalists, told itself that full-stack was the future, and is now surprised that the front-end is broken. None of that was bad luck. The industry chose it.

It means treating front-end as a specialism again. Hiring people who have that depth. People who’ve spent years learning why semantic HTML matters and what breaks without it, not people who looked it up last week. People who can look at a component and know (before the audit, before the user research, before the complaint lands) where it’s going to fail and why.

It means not outsourcing that judgement to a tool. AI can help. Automated testing can help. But neither can substitute for craft knowledge. The tools are only as useful as the person interpreting their output, and right now, on most teams, that person doesn’t exist.

The European Accessibility Act just made this problem legally uncomfortable to ignore. Teams that respond by ticking boxes will keep producing accessible-on-paper, broken-in-practice interfaces, and will keep being surprised when real users can’t use them. Teams that treat it as an engineering discipline, with real front-end expertise in from the start, will build something worth using.

No amount of AI-generated code, automated tooling, or compliance documentation will close that gap until the industry stops pretending that front-end is a layer anyone can handle.

It isn’t.