A Full WCAG 2.1 AA Audit, Run on a Multi-Agent Pipeline

The challenge

Somewhere in the customer base is an older, higher-value customer who opens the app to do something ordinary — check a balance, make a payment — and can't. Not because the product is broken. Because a button doesn't announce itself to a screen reader, or a focus ring vanishes, or a modal traps the keyboard. That customer doesn't file a bug. They just fail, quietly, and the business never sees it happen.

A design system is the highest-leverage place in a product organization to fix — or silently multiply — defects like that one. Every barrier baked into a shared button or modal propagates into every screen that uses it. This system had never been audited for accessibility. The default culture treated it as a final-stage checkbox, not a discipline owned up front.

The case for fixing it isn't abstract, and in this market it isn't primarily a legal one — accessibility law here binds only the public sector. So the case has to be commercial: the customer base skews older, and the older, higher-value customer is exactly the person whom low-vision, motor, and cognitive barriers hit hardest. A control you can't operate is a sale you don't make. At scale, it's brand and reputational risk. Underneath all of it, the same fact keeps returning: behind every finding is a real person who can't finish a task.

What I did

I took charge of a problem nobody owned. I stood up a full WCAG 2.1 AA program with a deliberate phase gate: Phase 1 audits the design source (Figma) to establish ground truth free of implementation noise; Phase 2 audits the real shipping code; then the two are reconciled. No mixed-surface shortcuts. Scope: all 19 components plus the underlying token foundations, audited on both surfaces.

The differentiator was the method. I designed the audit as a multi-agent pipeline: each component ran through an automated pass, which catches only a fraction of WCAG issues, plus a manual technique pass for everything automation misses — keyboard operability, focus order, screen-reader labeling, and everything else automation can't see. Then I directed an independent, adversarial verifier to re-check every report, prompted specifically to find what the first pass missed.

That verification is where the method was tested, not just demonstrated. Of 18 re-checked audits, 15 were materially corrected — not rubber-stamped. That's a real number to sit with: on a first look, most of what we thought we knew about our own compliance was incomplete. I'd built the pipeline on the premise that a single pass, even an automated one, isn't enough to trust — and the verification proved the premise right in a way I didn't fully expect until I saw the correction rate. It meant standing by a process that was, in effect, grading itself down in front of me, and using that as the reason to trust the final report more, not less.

"I'd built the pipeline on the premise that a single pass, even an automated one, isn't enough to trust."

I synthesized rather than just listing. A reconciliation matrix compared design against code and surfaced a systemic root-cause analysis — for instance, a palette-only token system with no semantic role layer turned out to be the single architectural root behind most contrast failures. I shipped a deliverable a committee can actually use: executive summary, a human-impact layer, a design route and an engineering route, per-component detail grouped by who owns the fix, a full findings registry, and methodology.

I made the report practice what it audits — self-accessible by design, passing its own automated scan with zero violations across every page, fully keyboard-navigable with visible focus and AA contrast. It's a live artifact I can demo on the spot, and it's built to be re-run: each pass produces a versioned report with computed deltas, so accessibility becomes something the organization tracks like a health metric, not something it commissions once and forgets.

When a real contrast defect reached production, I used it to write a durable team standard — "in UX, we are accessibility's line of defense" — made objective and measurable rather than debated. And I made the findings human: composite personas, age and ability archetypes, joined to the actual findings that would block them, translating 270 technical line-items into who they affect and why it matters.

Outcome & impact

A previously-unaudited design system now has a complete, two-surface WCAG 2.1 AA baseline: 270 findings, each attributed to a WCAG success criterion and to an owner. Underneath the number is the insight that actually moves the needle — a small set of root fixes resolves a disproportionate share of the severe findings, which turns a 270-line backlog into a short, fundable list.

More durable than the count is what the method produces on every re-run: a repeatable way to know, at any point, exactly where the system stands on accessibility — evidence a leadership team can act on instead of a one-time report that ages out of relevance. And there's a culture shift underneath the artifact: accessibility reframed as the team's own line of defense, backed by a standard anyone can apply without being an expert.

The report itself is the closing argument: a demoable, self-accessible artifact that earns executive attention because the medium reinforces the message. And it's genuine conviction, not performance — a 7-year throughline that goes back to launching a previous company's first accessible products.

What this taught me

The correction rate — 15 of 18 — was the real lesson, not a footnote. It taught me not to trust a single pass of anything, including a first read of my own team's work, and to build the check for that distrust into the process itself rather than into a review meeting after the fact. The program's proof is the report; the credit belongs to the design and engineering owners who took 270 findings and worked the fixes without getting defensive about them. My job was to build the method rigorous enough that their work would hold up in front of a committee.

Skills demonstrated

• Accessibility (WCAG 2.1 AA)
• Design-system governance
• Multi-agent AI orchestration
• QA method design (adversarial verification)
• Audit synthesis and root-cause analysis
• Human-centered framing (personas and prevalence data)
• Commercial framing of UX
• Building team standards and culture
• Technical reporting

Proof / artifacts