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 anymore.
This is the part of accessibility work that doesn’t get written about much. Not because it isn’t happening, but because it isn’t dramatic. The failure mode isn’t a designer who removed a focus outline or an engineer who didn’t understand semantic HTML. Those are the public-facing failure modes. 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.
This isn’t anyone’s fault, exactly. It’s what happens when you treat accessibility as a project that has an end.
A maintenance problem in disguise
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 periodically. Fixed in batches. Owned by nobody specifically. 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.
The maintenance frame matters because it 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, process, and tooling that lives in the development cycle.
Most organisations are still buying audits and wondering why the findings come back.
The role nobody quite owns
Here’s the structural thing that 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.
When something is everyone’s responsibility, the failure mode is predictable. It becomes the responsibility of 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 sustaining it actually looks like from inside
Some of this is going to sound mundane. That’s because it is.
It’s the PR comment on a colleague’s branch flagging that the new modal doesn’t manage focus, written carefully because you don’t want to be the person who makes accessibility feel like nagging. It’s the design review where you ask, again, whether the new colour token meets contrast, knowing the designer has been asked this before. It’s the documentation page you wrote that nobody reads, but that you maintain anyway 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 you’re not just listing fixes, you’re trying to capture why the patterns appeared in the first place so the next round of new 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 isn’t a marketing asset, it’s a legal commitment, and the practice needs 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.
The work is mostly invisible. It compounds slowly. It’s one of those things that, when it’s working, looks like nothing’s happening. When it’s not working, the audit report tells you.
What this all adds up to
Accessibility holds in organisations that treat it as a maintenance discipline with a named owner, not a project with an end date. The technical work is genuinely the easier half. The harder half is structural: making it someone’s job, building it into the development cycle, treating regression as a problem you actively prevent rather than discover six months later.
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 audit doesn’t sustain accessibility. The role does. 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. Resisting that absorption is most of what sustained accessibility work actually is.
The first audit is a start. The role is the rest of the work.