What AI just gave accessibility professionals back
For most of the last twenty years, accessibility specialists have done a job with two halves. One half is the work the field is actually about — judging whether alt text says what matters, evaluating whether a focus order matches the way a sighted reader would scan a page, deciding whether an error message helps the person who triggered it. The other half is the boring layer underneath: hunting for missing alt attributes, flagging headings that skipped a level, finding ARIA used in invalid combinations. Both halves were necessary. Only one was interesting.
In the last sixty days, the boring layer started handling itself. Not entirely, not perfectly, but enough that I think the shape of the job is about to change — and change in a direction that makes the work specialists actually trained for more visible, not less.
What just became automatic
axe-core became a Copilot input. GitHub shipped github/accessibility-scanner in May 2026: a GitHub Action that runs axe-core, files a structured issue for every finding, and hands those issues to Copilot to propose fix PRs. The novelty is not the scanner. axe-core has been around for a decade and has over four billion downloads. The novelty is that scanner output now feeds an AI that proposes the fix, instead of feeding a backlog that someone has to triage. The path from "missing alt text on a deployed page" to "PR open for review" no longer requires a human at every step.
Accessibility moved into the agent prompt loop. Community-Access shipped 79 accessibility-specialist agents across Claude Code, Copilot, Gemini CLI, and Codex CLI. DevAlly — a better-funded company in the same lane — ships a similar pattern with a procurement-friendly dashboard wrapped around it. We do not need to pick a winner among these to notice the pattern: accessibility is now something an AI assistant thinks about as it writes, not something a reviewer remembers to check before merging. The cheapest accessibility bug is the one that never lands in the codebase, and that bug is now meaningfully less likely to land.
The "AI-agent quality gate" pattern arrived for accessibility. In May, SonarQube shipped agent plugins that hook into Claude Code and Copilot. Snyk shipped an agent security scanner and embedded Claude into its platform. Code quality and security both got a native enforcement layer that lives inside the agent's loop, not next to it. Accessibility is the third leg of that triangle, and the same pattern — automated detection plus AI proposal plus human review — is now available in the same week, for the work we have been arguing belongs there for two years.
Three layers, same direction of travel. The mechanical end of accessibility work, which used to take meaningful time from people whose time was better spent elsewhere, can now be set up by anyone willing to add a GitHub Action and an MCP server to their project. That is the part that just became automatic.
For the accessibility specialists who have been doing this work for two decades, this is the boring layer of your job finally getting handled. The interesting layer — the part that needs your judgement — just became more visible, not less.
What's still craft
The new automation handles one slice of the work. The other slice is exactly where it was, and it is the slice the field has always been about.
A scanner can verify that an <img> has an alt attribute. It cannot verify whether the words inside describe what matters. A scanner can confirm that every interactive element is keyboard-reachable. It cannot tell you whether the order in which they are reached matches the way a sighted user would read the page. A scanner can flag that an error message exists. It cannot tell you whether the message helps the person who triggered it.
These gaps will not close with the next axe-core release. The WCAG success criteria that resist automation resist it on purpose: they were written to be judged by humans because the question they ask is about meaning, sequence, or context. AI helps — a model that has read the page can make a better guess about alt text than a regex ever will — but the judgement still has to be made, recorded, and defended.
What also has not changed is the evidence. A scanner that opens fifty issues and an agent that fixes twenty of them is a productive week, but it is not a conformance statement. The European Accessibility Act, DOJ Title II, and UK Equality Act all ask the same shape of question: which criteria did you evaluate, what did you find, how did you verify the fixes, where is the trail? "We ran a scanner" answers none of those. The detection became automatic. The accountability did not.
What this frees you to do
If your team adopts github/accessibility-scanner this week, you will close real bugs faster than you would have last quarter. If you install Community-Access or DevAlly into your CLI, your AI assistant will stop suggesting <div onclick> and start suggesting <button>. Both moves are worth making, and both will give specialists back time they were spending on the mechanical end of the work.
The interesting question is what to do with that time. Three suggestions:
Spend some of it on the criteria scanners cannot see. Pick three success criteria your team has been quietly under-evaluating because they require judgement — 2.4.3 Focus Order, 1.3.3 Sensory Characteristics, 3.2.4 Consistent Identification are good candidates — and actually evaluate them. The scanner's not going to.
Spend some of it on evidence. The reason most teams cannot answer "what is your WCAG conformance position?" is not that they have done no work; it is that the work they did was not tracked in a shape an auditor recognises. Now that detection is automatic, the bottleneck moves to evaluation and proof. Build the trail while the bugs are fresh.
Spend some of it on the people who will use what you ship. This is the work that has always been worth doing and that no tool, AI or otherwise, will do for you: keyboard testing, screen-reader testing, talking to users who actually rely on this stuff. The time the scanners gave back is the time that work fits into.
A good problem to have
Two months ago, the lane between "AI writes code" and "code is accessible" was empty. Today, GitHub, a community of maintainers, several specialist startups, and the established quality and security vendors are all shipping into it. That is unambiguously good news, especially for the specialists who have been carrying this work for years — because the floor is rising, and a rising floor is what makes the harder layers of this work matter more, not less.
We built Jeikin for the layer that did not become automatic. The 86 WCAG criteria still need to be evaluated, the fixes still need to be verified against the criterion they claimed to satisfy, the evidence still needs to be auditable. That work used to be hidden under the much larger pile of "missing alt text" and "wrong heading levels," and now that pile is shrinking, the work specialists trained for is what is left in plain view.
If you are deploying the new generation of accessibility tooling in your codebase, do it. The mechanical layer is not the work anyone got into this field to do. Then come talk to us about the layer that is left — the layer that has always been the one that matters.
The detection layer is now everyone's. The judgement layer is still yours. We built Jeikin to make that judgement layer easier to do, prove, and defend.