Building Accessibility Auditing Into Agent-Driven Workflows

Why We Built the Accessibility Testing Tool as a CLI for AI Agents

The tool is a command-line tool exposed to AI agents such as Claude Code and OpenAI Codex. The agent loads a skill, runs the accessibility checks, and produces an HTML report.

Building it this way was a deliberate choice. Developers already work with these agents, so an accessibility auditor that runs as one more command fits their existing workflow instead of asking them to leave it.

Because the checks run in parallel, a full pass finishes quickly enough to sit inside everyday development rather than a scheduled audit.

Automation and AI: Choosing the Right Layer for Each Check

Our first instinct was to run everything through AI. The token cost and the time cost made that impractical.

So we split the work. Automation handles the mechanical, deterministic checks, and AI handles the contextual judgment a human auditor used to make, such as whether an image's alt text is meaningful rather than merely present.

We go deeper into that split in AI vs. Automation: What's the Difference and How to Choose the Right Layer, and into the audit mechanism itself in How We Use AI to Accelerate Web Accessibility Auditing. 

Here the point is narrower: the layer split is what keeps the tool fast and affordable enough to run continuously.

Why We Use Only Playwright's Engine for Faster Accessibility Checks

To keep the tool fast, we use only the engine part of Playwright that runs the testing, not the full framework. That lets us run 10 or 20 checks in parallel without the overhead a full suite would add.

Speed is what makes continuous testing realistic. A pass that finishes quickly can live in continuous integration or a pre-publish step. One that takes much longer gets pushed to the end, which is the problem we set out to avoid.

As Rosa explained during the session, the checks map to WCAG criteria, with at least one test per guideline, and AI supplies the contextual judgment on top. 

For the full metric framework behind that, see Beyond Basic Compliance: Our Web Accessibility Audit Approach and Metrics.

The Audit-and-Fix Loop

Because the auditor runs as an agent tool, it can do more than report problems. Give it the code of the page, and it can apply fixes or lay out the trade-offs of different fixes.

This is where running as an agent, rather than as a standalone scanner, changes what the tool can do. A traditional auditor hands back a list of findings and stops there, because it has no access to the code and no way to act on it. An agent that already works inside the codebase can take the next step, turning a finding into a proposed change in the same pass.

Not every fix should be automatic. Some issues have one clear correction, such as a missing language attribute, while others involve a judgment call, such as how to reword alt text so it carries real meaning. For those, the tool can explain the options and their trade-offs instead of guessing, and a person makes the decision.

That turns an audit from a list of findings into a starting point for changes. The report tells you what is wrong, and the same tool helps you close the gaps, with a human staying in the loop for the calls that need one.

How an Agent-Native Auditor Fits CI/CD and Pre-Publish Workflows

The design pays off where accessibility testing needs to live. A fast, agent-callable CLI slots into three places:

• Continuous integration, running on each build before code merges.
• Pull-request review, where an agent runs the check as part of automated review.
• Pre-publish steps, catching content issues like missing alt text before they ship.

None of this requires a separate accessibility platform. The tool is small enough to add to the pipeline you already run.

See What Our A11y Audit Tool Finds on Your Own Site

The fastest way to understand what an agent-native auditor changes is to point it at your own site. We can run it against your pages, show you the accessibility issues it finds, and walk through which ones automation caught and which ones needed AI's judgment.

From there, we look at how the tool fits the way your team already works, where the checks belong in your continuous integration and pre-publish steps, and what it takes to make accessibility a routine part of how you ship. 

Our Web Accessibility service is where we do this work with teams.

Want to see it on your site? Schedule a demo with our team.