The AI tools that broke accessibility just became the only place to fix it
Ask a large language model to build you a sign-up form and, left to its defaults, it will hand you a <div onclick> where a button should be, an icon with no label, a placeholder standing in for a real <label>, and a focus order that follows the DOM instead of the eye. None of this is malice and none of it is incompetence. It is the median of everything the model has read, and the median of the web has never been accessible. For two years, AI code generation has been a firehose pointed at production, and most of what comes out the end has the same accessibility gaps the web has always had, now produced faster than any review process was built to catch.
Here is the turn that makes this an interesting moment rather than a familiar complaint. On June 30, 2026, Siteimprove launched an MCP server that embeds its accessibility agent directly into Claude, VS Code, Figma, and Lovable. Siteimprove is a twenty-year-old company whose whole model was scanning finished websites and handing governance teams a dashboard. When a company built around after-the-fact scanning moves its agent into the editor where code is written, that is a signal about where the whole category is heading.
Everyone arrived at the same place
Siteimprove is one data point, and on its own it would be a press release. What makes it worth writing about is that it is the latest arrival at a destination the entire field reached this year.
In May, GitHub shipped its own accessibility scanner as a first-party Action that files issues and hands them to Copilot to fix. A community pack shipped 79 accessibility agents that ride along inside Claude Code, Copilot, and Gemini CLI. Deque's axe engine, Level Access, and a wave of MCP servers we compared earlier this year all point the same direction. The names differ and the packaging differs, but the premise underneath every one of them is identical: accessibility has to live inside the tools where code and content are made, at the moment they are made.
That premise used to be an argument. We spent a year making it, and so did a lot of other people. It is now the consensus position of an entire industry, incumbents included. The cheapest accessibility gap to close is the one that never reaches the codebase, and the place to close it is the authoring loop.
So the interesting question is no longer whether accessibility belongs in the loop. Everyone agrees on that now. The interesting question is what a tool has to actually do once it gets there.
Two very different things wear the same clothes
"Accessibility in your AI workflow" describes two mechanisms that look alike in a demo and behave nothing alike on a real project.
The first is suggest-and-hope. An agent notices a missing label, mentions it, maybe proposes a fix, and moves on. Whether the fix lands, whether it was correct, whether it survives the next refactor two prompts later — all of that is left to a human who is already juggling six other things. Suggestions are genuinely useful. They raise the floor. A model that flags a <div onclick> as you write it is better than one that stays quiet. But a suggestion is advice, and advice is easy to lose. The agent that recommended a fix on Monday has no memory on Friday that the recommendation was ignored.
The second is enforce-and-verify. Here the workflow does not end at the suggestion. Every finding is tracked. Every fix is checked against the criterion it was meant to satisfy. And the result is written down somewhere durable, so that "we handled accessibility" is backed by a record of which criteria were evaluated, what was found, and how each fix was confirmed. We wrote about this gap directly in why finding issues was never the problem: detection has been a solved problem for a decade, and the compliance work still fell apart, because finding an issue and proving it was fixed are separated by everything that actually matters.
Both of these can be delivered through an MCP server. Both can claim to put accessibility "in the loop." Only one of them produces something you can stand behind when someone asks what you did and how you know it worked.
What "in the loop" has to mean to count
If the category has agreed on the location, the standard to hold every tool to is what happens after the finding. A workflow earns the phrase "accessibility in your AI loop" when it does three things, in order:
- Track, not just mention. Every finding becomes a tracked item, not a line of chat that scrolls away. If it is invisible tomorrow, it did not happen.
- Verify against the criterion. A fix is confirmed against the specific thing it was meant to satisfy. An automated re-check for the parts a machine can judge, and a recorded human decision for the parts it cannot. Automated scanning covers a real slice of WCAG, and we have been honest about which slice: roughly the third of criteria with a clean computational definition. The rest is judgement about meaning, and judgement has to be recorded, not assumed.
- Leave a trail. The output is evidence. Which criteria were evaluated, what was found, how each fix was verified, when. The W3C's own guidance on conformance is built around this shape of record, and no amount of in-editor cleverness replaces it.
A tool that does the first without the second and third is a smarter linter. Valuable, and still short of the thing regulators, procurement teams, and your future self are actually going to ask for.
The part worth building for
The consensus that accessibility belongs in the authoring loop is good news, and it belongs to no single company. When incumbents move their agents into the editor, they are validating a direction the whole field has been walking toward, and more tools raising the floor is exactly what should happen.
This is where Jeikin has been pointed from the start. A Jeikin review does not stop at the finding: it reports each issue to a dashboard, checks each fix against the criterion it was meant to satisfy, and keeps the evidence trail as the actual output of the work. The suggestion is the beginning of the job. The verified, recorded fix is the job.
I can tell you what that feels like in practice, because I build other products with Jeikin in the loop. There are days it slows me down. I want to ship a component, and Jeikin asks me to track the finding, get the guidance, verify the fix, and prove the check passed before it will call the work done. In the moment, that friction is real, and I feel it.
But I have come to read that friction as the tool doing exactly what I asked it to. A workflow that never stops you is not enforcing anything; it is narrating. The moment Jeikin makes me slow down is the moment a <div onclick> would otherwise have shipped, or an alt text that describes the wrong thing would have passed unquestioned. The pause is the enforcement. Take the pause away and you are back to suggest-and-hope, back to a floor that drifts down every time someone is in a hurry.
That is the trade the whole category is now choosing between. Accessible code has a cost, and the cost is a little friction at the moment of writing, paid by the person best placed to fix it, when it is cheapest to fix. The alternative is not "no cost." It is the same cost moved downstream, to an audit months later, to a person who has to reverse-engineer intent from finished markup, to users who hit the barrier first. Enforcement chooses to pay early. That is the whole idea.
The location debate is over, and the industry landed in the right place. What comes next is the standard we hold the whole category to now that it is here: not just noticing accessibility in the loop, but tracking it, verifying it, and being willing to be slowed down by it when it counts.
The next time an accessibility tool makes you stop and do the extra step, notice what it just caught. If the answer is "nothing I could not have skipped," you have a narrator. If the answer is a real barrier that will not reach a real person now, that pause was the point.