You've Made a Start. Then What?

The audit closes. The findings get logged. Tickets get raised, some of them get fixed, and the organisation moves on with a slightly shorter list of accessibility issues than it had before. Six months later, most of those findings will be back. Different components, sometimes, but the same patterns. The next audit will produce a list that overlaps with the last one in ways nobody’s surprised by any more.

This is the part of accessibility work that doesn’t get written about much. It’s just dull. The failures everyone knows are the designer who binned the focus outline and the engineer who never learnt semantic HTML. The quieter one is what happens after the audit, when the people who care about accessibility try to make the fixes hold.

The pattern after the audit

I’ve watched this play out in three organisations now and it’s the same shape every time.

Audit lands. Findings get triaged. The big ones get assigned to teams who have a fortnight to fix them before the report goes out to whoever commissioned it. The small ones get added to a backlog where they sit indefinitely, occasionally getting picked up when someone has spare capacity and remembers them. The middle ones get fixed in the components that were audited and not fixed in the components that weren’t, because nobody’s job is to extend the fix laterally.

Six months pass. New features ship. Old components get extended. The components that were fixed get touched by engineers who weren’t around when they were fixed, and the fixes erode because the engineer doesn’t know what the fix was for. New components get built that repeat the same patterns the audit just flagged, because the audit findings never made it into the documentation, the linting, the code review checklist, or the engineer’s working knowledge.

Audit number two is commissioned. The findings overlap with audit number one’s findings in ways that, if you stared at them long enough, would tell you something specific about what went wrong. Mostly nobody stares at them long enough. The fixes get re-raised. The cycle continues.

Nobody’s to blame, exactly. Treat accessibility as a project with an end and this is what you get.

Accessibility is maintenance

The disciplines that figured this out years ago are security and performance. Both started as exceptional concerns: things you brought in a specialist for, audited periodically, fixed with a project, and considered done. Both eventually got reframed as ongoing engineering work, because the field collectively realised that anything you treat as a one-off audit will regress.

Security has SAST scanners in CI. Dependency vulnerability checks. Threat modelling baked into design review. A security champion in every team. A platform team that owns the standards and the tooling. Performance has lighthouse budgets, RUM telemetry, regression alerts, performance reviews of new features before they ship. Both have role definitions, certifications, recognised career paths.

Accessibility is, in most organisations, still where security was in 2008 and performance was in 2012. Audited now and then, fixed in batches, owned by nobody in particular. Considered solved when the report comes back clean, even though the report is a snapshot of one moment in a system that changes every day.

Seeing it as maintenance changes what good looks like. If accessibility is a project, success is ‘no findings in this audit’. If accessibility is a maintenance discipline, success is ‘we caught the regression in PR review, before it shipped’. Those are different problems with different infrastructure. The first one needs an audit budget. The second one needs people and tooling inside the development cycle.

Most organisations are still buying audits and wondering why the findings come back.

The role nobody quite owns

This is the bit nothing else fixes.

Accessibility, in most organisations, is everyone’s responsibility. Which means it’s nobody’s job. The designer is supposed to consider it. The engineer is supposed to implement it. The QA is supposed to test it. The product manager is supposed to prioritise it. The accessibility champion in the team is supposed to advocate for it, in the time they have left over after their actual job. There’s no individual whose performance review depends on whether accessibility holds.

So it lands on whoever cares most, which means the work falls on the same two or three people across the organisation, who burn out or leave. Their replacements don’t pick it up because there’s no role definition saying they should. The institutional knowledge walks out the door with the person who built it.

The fix is unglamorous: name the role, give it real authority, fund it. Not ‘accessibility champion’. That’s the volunteer pattern that creates the burnout. A specialist, full-time or close to it, whose remit is the standards, the tooling, the review, the training, the audit response, the regression prevention. The person whose job depends on whether accessibility holds.

A few organisations have figured this out. Most haven’t. The ones that have tend to be the same ones that get accessibility right structurally. They’ve made it someone’s job, given them backing, and held them accountable for the outcome. The rest run on volunteer enthusiasm until the volunteers run out.

What it looks like from inside

You write a PR comment saying the new modal doesn’t manage focus, and you word it carefully so you don’t become the accessibility nag. You ask in the design review, again, whether the new colour token meets contrast, knowing the designer has been asked this before. You maintain the documentation page nobody reads, because the day someone needs it they’ll need it badly.

It’s the audit response document that takes two weeks to write properly because a list of fixes isn’t enough. You have to say why the patterns appeared, so the next round of components doesn’t repeat them. It’s the conversation with the engineering manager about why the linting rule that catches missing alt text needs to fail builds rather than warn, and the follow-up six weeks later when it gets reverted because it slowed down a sprint. It’s the slow, repeated argument that the accessibility statement on the website is a legal commitment, and the practice has to match the wording.

It’s noticing that the new junior engineer’s first PR has three accessibility issues, and choosing whether to flag them now or build the relationship first and flag them next time. Deciding, eventually, that you’ll always flag them, but you’ll do it in a way that teaches rather than corrects. Recognising that this calculation is your job, not theirs.

It’s the small win of someone, one day, asking the question before you’ve had to. The new designer who annotates focus order in the spec without being prompted. The engineer who pushes back in review on a colleague’s commit because the markup doesn’t carry through to the accessibility tree. These moments mean the foundations gap is closing somewhere. They are also rare enough that you remember them.

When it’s working, it looks like nothing’s happening. When it’s not working, the audit report tells you.

Most organisations aren’t there yet. The ones that are tend to have got there because someone fought the case internally for long enough that the structure changed around them. That fight is part of the work, even when it doesn’t feel like it. The role doesn’t exist by default. Someone has to make the case for it, then keep making it.

If you’re the person inside an organisation trying to make this hold, the pattern is recognisable and it isn’t your fault. The system is designed to slowly absorb accessibility work into background hum until the next audit. Most of the job is stopping that from happening.