GAAD turns 15: accessibility built in, not bolted on

Most conversations about accessibility go one of two ways. Either they stay at the level of moral imperative - the “right thing to do - or they collapse into compliance theatre: a list of regulations, a threat of fines, a one-off audit ticked off and forgotten.

Neither version is useful for a product team.

So for Global Accessibility Awareness Day (opens in a new tab) this year, we did something different. We put two people in the hot seat — Cian Dowling, Accessibility Lead at Synthesia, and Darren Britton, our CTO and Co-Founder — and asked them to talk honestly about what this work actually looks like from the inside. No slides. No polished answers. An open floor.

Here’s what you missed:

The flood defence nobody builds until after the flood

Cian has a frame for accessibility that cuts through the usual arguments faster than any regulatory threat.

"If you have the most perfect flood defences and a flood doesn't happen, who’s gonna give you a pat on the back? Nobody. But don’t have them? It’s your neck on the chopping block.

It is only when the event hits that it matters to your pocket. What happens if someone says, “I’m going to turn you down for the biggest contract you have ever had because you don’t have a VPAT,” - everybody loses, not just the engineers."

This is the conversation most product teams are avoiding. Not because they don’t care about accessibility, but because the business case has not landed yet. Accessibility sits in the same category as disaster recovery: invisible when it works, catastrophic when it does not.

The difference now is that the flood is closer than most teams think.

Nobody cares about compliance until it is too late

Cian's first call when he joined Synthesia was not to the accessibility community. It was to the Head of Infosec.

"I asked him: tell me what happened ten years ago with GDPR. How did you get people to care before it was too late? He gave me a lot of good advice."

The GDPR analogy is the most useful one in the room for a mixed audience. Most product teams have been through a compliance cycle — SOC 2, GDPR, ISO 27001. They get the pattern: it feels optional, then it feels urgent, then it is a condition of doing business with anyone that matters. Or else lose out.

Accessibility is in the same cycle, two or three years behind. The companies that are treating it as infrastructure now are the ones that will close enterprise deals in 2026 and 2027. The ones waiting will be retrofitting under pressure (and that stuff’s expensive).

"I would much rather take proactive steps and get something into a roadmap for next quarter that addresses 20% of it, than sit around complaining that we have not hit 100%."

Progress over perfection.

The audit is not an NCT

Here is the trap most teams fall into. They commission an audit. They get a report. They treat the report as the work. And forget about it.

Cian's view on this is direct: the audit tells you what was wrong at a point in time a few months ago. For a company shipping over a thousand things a month, that picture is stale before you finish reading it.

"I am way more interested in figuring out how to reduce the amount of inaccessible things we ship month on month than clearing a backlog. The audit is not like an NCT on your car — you do not go once a year and tick the box. The question is: what are the things that led to those issues being there, so that the next audit has fewer?"

That is a definition-of-done question. Not a remediation sprint question.

The teams making real progress on accessibility are the ones that have stopped treating it as a project and started treating it as a practice. Accessibility owned by a champion (or several) embedded in product or engineering. Built into the design system so it is right by default.

AI is not going to solve this. It might be making it worse.

The question we hear most from product teams right now: will AI not just fix this automatically? Can we not run our codebase through Claude or GPT and get our accessibility issues resolved?

Cian tried to build an AI accessibility tool himself before he joined Synthesia. Here is why it does not work the way most people assume.

"If you stick your whole codebase through an LLM, you are giving away the family farm. You do not really want to be putting your proprietary code into a third-party model."

But the deeper problem is what AI has been trained on.

"LLMs are trained on everything that has happened to date. 97% of the internet is not accessible. That means that AI has been trained predominantly on inaccessible code. So the output reflects that."

AI-generated React components routinely skip ARIA and semantic HTML. Runtime-generated interfaces cannot be pre-audited. The speed at which AI allows teams to ship means accessibility regressions arrive before anyone reviews them. The tools promising to help teams move faster are, for many teams, quietly writing compliance debt into every release.

That does not mean AI has no role. It means the role is different to what most people assume.

"Taking the volume and scale of what AI can do, but adding human judgement and context to reduce the work - that’s what you need. A tool like DevAlly lets an accessibility specialist, or an accessibility-minded engineer, do 5X the work they could otherwise do. You are not going to get that from a generic off-the-shelf LLM."

The angle nobody is talking about yet

There is a thread that is just beginning to surface in engineering conversations, and it reframes accessibility for the boardroom in a way that moves it out of the compliance column entirely.

AI agents are increasingly users of software. And the same structural qualities that make a product accessible to screen reader users — semantic HTML, proper labels, predictable component architecture, correct ARIA roles — are the qualities that make a product navigable by an AI agent.

Teams investing in accessibility now are accidentally building the foundation for agent compatibility.

If your product cannot pass a screen reader, it probably cannot pass an agent either.

Accessibility stops being a compliance cost. It becomes part of your AI-readiness story.

What to do this week

The room at GAAD asked for one practical action each. Here is what our speakers landed on.

Darren Britton, CTO and Co-Founder, DevAlly: Start with your top three user journeys. Not a full audit. Automate what you can, flag what needs human eyes. Get something visible to the engineering team this sprint.

Cian Dowling, Accessibility Lead, Synthesia: Do not go talk to the accessibility community first. Go talk to your Head of Infosec. Ask them what happened ten years ago with GDPR. Ask how they got people to care before it was too late. That is the conversation you need to replicate — and then find the vector that gets you onto the engineering planning schedule.

And from both: do not commission a report and treat it as the work. The report is the start of the work.

The honest version of this story

Cian said something early in the conversation that is worth sitting with.

"It is a thankless task when you are talking about compliance. Nobody cares about it until it is too late. But I do not think it is good enough to sit around saying we should do this. We ship things fast. Like a lot of the best things in life, you see the opportunity and you have to bite at it and go for it."

Accessibility built in from the start is not just the responsible choice. At a $4bn AI company shipping over a thousand product changes a month, it is the only choice that makes commercial sense.

That is what built in, not bolted on actually looks like.

DevAlly is a Dublin-based accessibility compliance platform. We help product and engineering teams detect accessibility issues early, manage prioritised remediation backlogs, and generate the conformance documentation enterprise procurement now demands.

Want to know where your product stands? Run a free scan at devally.com