Article
Accessibility Is Not A Scanning Problem
Accessibility is having a tooling moment.
Scanners are faster. Browser extensions are better. AI-assisted audits are appearing everywhere. If you spend any time around product, agency or CMS conversations right now, it is easy to come away with the impression that accessibility is finally becoming something software can mostly handle for us.
I do not think that is true.
Useful? Yes. Necessary? Often. Sufficient? No.
That distinction matters, because a lot of teams are in danger of turning accessibility into a scanning problem when it is really a design, content and quality problem.
What The Standards Already Tell Us
The useful starting point here is not hype. It is the guidance we already have.
W3C's accessibility evaluation guidance is very clear: tools help, but no tool on its own can determine whether a site meets accessibility standards. Human evaluation is required. WCAG 2.2 makes the same point in slightly different language, describing conformance as something that depends on a combination of automated testing and human evaluation.
That should immediately lower the temperature.
Accessibility is not a magic pass or fail badge that falls out of a scan. It is a discipline of checking whether real people can actually use what you built.
The Recent Research Is Useful, And Slightly Sobering
Two recent papers are worth paying attention to.
The first, a May 2026 systematic literature review of large language models in web accessibility, found that most current LLM-based work is focused on text-centric and structurally explicit tasks. That makes sense. These are the areas where patterns are easiest to detect and score. But the same review also noted limited attention to cognitive accessibility guidance.
That gap matters more than it may first appear.
Many of the hardest accessibility problems are not simple markup defects. They are questions of clarity, predictability, cognitive load, interaction design and whether the interface makes sense under pressure. Those are exactly the areas where teams most need judgement.
The second paper, published in February 2026, looked at colour contrast across heavily crawled websites and found that 40.9% of sampled foreground and background pairings failed the standard threshold for normal text.
That is not a story about obscure edge cases. It is a reminder that even highly visible websites still miss the basics.
So on one side we have better tools and more research interest. On the other, we still have widespread failures in straightforward areas and weaker coverage in more nuanced ones.
That feels familiar, because it mirrors what happens on real projects.
Why Accessibility Still Slips Through
Most accessibility issues do not appear because nobody ran a scanner.
They appear because accessibility was treated as a late-stage check rather than a delivery habit.
Sometimes the problem is design: text that technically passes a brand review but not a contrast requirement, or interactions that look clean in a mockup but become awkward on a keyboard.
Sometimes it is content: vague link labels, poor heading hierarchy, unhelpful form errors, instructions that assume too much, or alt text that exists but does not actually help.
Sometimes it is product thinking: authentication flows that become hostile under real-world constraints, drag interactions that exclude people by default, or help patterns that disappear just when someone needs them.
A scanner can catch some of that. It cannot own it.
Where Automation Genuinely Helps
This is not an argument against tools. Quite the opposite.
Automated checks are excellent at surfacing recurring defects early. They are useful in CI. They are useful during template work. They are useful when reviewing editorial output inside a CMS. They are useful as a baseline guardrail that stops obvious regressions being normalised.
AI also has a real role here when used carefully.
It can help triage patterns, suggest likely fixes, flag suspicious copy, and accelerate parts of a review that would otherwise be repetitive. In content-managed environments especially, that can be valuable. If you are maintaining a large archive or a site with multiple contributors, that kind of support can save time and reduce drift.
But acceleration is not the same as understanding.
The tool may identify that a button lacks a label. It cannot reliably tell you whether the surrounding journey is calm, comprehensible and fair to the person using it. It may suggest alt text. It cannot know whether that description is meaningful in the context of the page's purpose. It may identify a focus issue. It cannot decide whether the overall interaction model is sensible.
That is still our job.
The More Honest Delivery Model
The better model is not accessibility by scanner. It is accessibility by workflow.
That means checking early in design, during build, in content entry, and again in realistic review. It means mixing automated checks with keyboard testing, content review, structured manual evaluation and, where possible, direct involvement from people with relevant lived experience.
It also means being honest with clients and teams about what tools can and cannot prove.
There is a lot of commercial pressure to present accessibility as a neat compliance output. Buy the platform. Run the scan. Get the report. Job done.
Real delivery is messier than that.
If accessibility is important, and it is, then it belongs inside design reviews, component thinking, CMS structures, QA habits and editorial standards. It cannot be bolted on by a dashboard after the fact.
Why This Matters More Now
The reason I think this matters right now is precisely because tooling is getting better.
When software becomes more capable, teams are tempted to hand over the thinking with the task. That is understandable. It is also risky.
Good accessibility work benefits from better tooling. It does not become fully automatable because better tooling exists.
In some ways, the rise of AI makes disciplined human judgement more important, not less. If a tool can produce fixes quickly, the cost of shipping the wrong fix also drops. You can end up moving faster in the wrong direction unless someone is still asking whether the result is genuinely usable.
That is the standard worth keeping.
Accessibility is not a scanning problem. It is a quality problem, a design problem, a content problem and, ultimately, a responsibility problem.
That is harder to package, but closer to the truth.
Sources
Need senior support on a web project?
Bring in focused technical help for planning, build, review or long-term support.