The audit is not the fix: closing the accessibility remediation gap

A team we spoke with had a 180-page accessibility audit sitting in a shared drive. It cost real money, it was thorough, and it was eleven months old. When we asked how many of the findings had been fixed, nobody could say — not because they were disorganized, but because the audit and the codebase had never been connected to each other. The findings lived in a PDF. The code lived in GitHub. Between those two things was a gap that no one owned.

That gap is the actual problem in web accessibility right now. Not detection. Detection is close to solved: axe-core is open source, browser devtools ship accessibility panels, CI linters catch violations on commit, and any team that wants a list of WCAG failures can generate one this afternoon for free. The industry has spent a decade getting very good at telling you what is broken and almost no time getting good at fixing it.

Why findings stall

An audit finding is not a work item. It is the raw material for one, and converting it takes engineering judgment that the audit does not include.

Consider a typical line: "Form input at /checkout step 2 lacks a programmatically associated label. WCAG 1.3.1 (A), 4.1.2 (A). Severity: critical." Everything in that sentence is correct. None of it tells the engineer which component renders that input, whether the label is missing in one instance or in a shared component used in forty places, whether an existing aria-label elsewhere makes the fix redundant, or whether the design system owns that primitive and the fix belongs in a different repo entirely.

So the finding gets triaged. Someone opens a ticket, writes "investigate," and drops it in the backlog. It now competes with feature work, and it loses, because feature work has a stakeholder and this has a document. Multiply that by four hundred findings and you have the pattern we see constantly: high audit spend, low remediation rate, and a compliance posture that has not moved since the invoice was paid.

There are four specific reasons this happens.

Findings are page-scoped, code is component-scoped. Audits report per URL. A single shared button component with a contrast failure generates eighty findings across eighty pages, which reads as eighty problems and is actually one. Teams either over-estimate the work and freeze, or fix it in one place, close one ticket, and leave seventy-nine open.

The finding does not survive translation. By the time a URL-and-selector pair becomes a Jira ticket, the person writing the ticket has usually never opened the file. The engineer picking it up starts from scratch: reproduce, locate, understand, fix, test. The audit saved them the detection step and nothing else.

Nobody owns the aggregate. Individual tickets have assignees. The overall compliance state has a stakeholder in legal and no owner in engineering. When each ticket is small and the aggregate is what regulators care about, the incentives are pointed at exactly the wrong scale.

The report is a snapshot of a moving target. Two sprints after the audit, half the audited screens have been redesigned. Some findings are stale, some are still valid, and no one can tell which without re-testing. Confidence in the document drops, and a document nobody trusts stops driving work.

The detection surplus

It is worth naming how lopsided the tooling market has become. Point a scanner at a site and you get findings in seconds. Add an ESLint plugin and you get them at the moment of writing. Add a CI check and you get them on every pull request. Add a monitoring platform and you get them on a dashboard, trended over time, sliced by team.

All of that is genuinely useful and none of it writes a line of code.

The WebAIM Million — an annual automated analysis of home pages published by WebAIM at Utah State University, and the most-cited dataset in this field — is a fair illustration. It has run for years, and each edition finds detectable WCAG failures on the overwhelming majority of pages tested, with the same handful of failure types dominating every year. Check the current edition on WebAIM's site for the exact figures. The interesting part is not any single number. It is that the same categories of failure recur annually, which tells you that visibility alone has not been the constraint. We can see these problems fine. We are not fixing them.

Meanwhile the automated-versus-manual split gets quoted constantly — the rough claim that automated tooling catches only a minority of WCAG issues, with the rest requiring human judgment. Deque, which maintains axe-core, publishes its own analysis of what automated testing covers; that is the source to read rather than the secondhand percentages that circulate. Either way, the honest reading is not that automation is weak. It is that even the portion machines can reliably detect is largely not getting fixed. There is no shortage of findings. There is a shortage of merged diffs.

What actually closes the gap

A finding becomes a fix when three things are true: it is located in source, it is expressed as a diff, and it enters the workflow engineers already use.

Located in source. A URL and a CSS selector are a starting point. A file path and a line number are an assignment. Scanning the repository rather than only the rendered page is what makes the difference — it collapses those eighty page-level findings into the one component that caused them, and it tells you whether the fix belongs in a leaf component or a design system primitive.

Expressed as a diff. The unit of accessibility work should be a code change an engineer can read, not a description of a code change. A diff is reviewable in a way prose is not. You can disagree with it precisely, amend it, or reject it in thirty seconds. A ticket that says "add an accessible name to the icon button" requires the engineer to make five small decisions before they write anything; a diff proposes all five and asks them to confirm.

In the existing workflow. Accessibility work that lives in a separate portal is accessibility work that gets checked when someone remembers. Work that arrives as a pull request goes through the same review, the same CI, the same merge queue, and the same approval as everything else. It stops being a special category and becomes normal engineering.

This is the design constraint we built inklu around. It scans against WCAG 2.2 using axe-core v4.11 plus 50-plus rules we wrote on top, and then generates fixes as GitHub pull requests — HTML, CSS, SCSS, and JSX including TSX today, with Angular on the roadmap. Fixes never go to your default branch; every change is a PR you review and merge or close. It runs in GitHub Actions so violations get caught on pull requests rather than in a quarterly report. Source code is purged after each scan.

The reason for the PR-shaped output is not novelty. It is that a pull request is the only artifact in this entire chain that someone is already obligated to look at.

What this does not replace

Automated remediation closes the mechanical part of the gap. It does not close all of it, and any vendor telling you otherwise is selling you the same over-promise that made overlays a cautionary tale.

Cognitive load, plain-language content, meaningful alt text, whether a flow makes sense to someone using a screen reader end to end, whether an error message actually helps — these need people. So does testing with assistive technology and, ideally, with disabled users. A tool can tell you an image is missing alt text; only a human knows whether the image is decorative or carries the meaning of the paragraph.

The right shape is division of labour. Let automation handle the high-volume, mechanically-determinable failures — missing labels, contrast ratios, ARIA misuse, focus order, target sizes — so that expensive human audit time goes to the judgment calls. If your auditors are spending their hours writing up missing alt attributes, you are paying senior rates for work a machine does better, and the genuinely hard findings are getting less attention than they deserve.

We wrote more about where each category of tool actually helps in the state of web accessibility tooling in 2026, and about the failure mode at the other extreme in overlay widgets vs source-code fixes.

A blunt question for your next audit

Before you sign the next statement of work, ask the vendor one thing: what does your deliverable look like on the day my engineer sits down to fix something?

If the answer is a report, price the engineering time to convert it. That conversion cost is real, it is usually larger than the audit fee, and it is the line item that quietly does not get budgeted — which is exactly why the PDF is still in the shared drive eleven months later.

If you want to see what remediation looks like when it arrives as a diff instead of a document, book a demo at inklu.io, or email hello@inklu.io. Pricing is token-based and every plan gets every feature — the details are on the pricing page, and the FAQ covers what we do and do not support today.