AI design accessibility audit: Catch accessibility problems in the design file, not in the bug tracker

Category: Product & Design

ZeroTwo reads the Figma frames for a feature, checks the criteria that can be checked from a design — contrast, target size, text scaling, focus order, labelling — and files prioritized Linear tickets that name the exact frame and the WCAG criterion behind each finding.

Integrations: figma, linear, slack

What Changes

Dimension	Before	With ZeroTwo
When problems surface	Accessibility issues are found in QA or after release, once they cost engineering time	Contrast, target size, and labelling gaps are caught while the frame is still editable
Where the fix belongs	The same failing colour pair is filed as a separate bug on every screen that uses it	Token-level failures are filed once against the design system
What counts as reviewed	A checklist is marked complete with no record of which criteria were actually evaluated	Each finding names its WCAG criterion, the frame, and the measured value
Manual testing	Assistive-technology testing is skipped because nobody knows what is still unverified	Criteria a design cannot settle are listed explicitly as outstanding

Why teams use ZeroTwo for accessibility audits

Mechanical findings cleared early — Contrast ratios, target sizes, and missing accessible names are the bulk of most audit backlogs and the cheapest to fix while the design is still open.
Fixes land at the token level — Tracing a failure back to the shared style turns dozens of per-screen tickets into one design system change.
Honest about what it cannot check — Criteria that need real markup or interaction are reported as outstanding rather than passed, so a clean report is not mistaken for a conformant product.
Tickets engineers can act on — Each ticket carries the frame, the criterion, the measured value, and a concrete suggested change instead of a screenshot and a note saying it fails.

Accessibility review arrives too late to change the design

Most accessibility work starts after a feature is built. QA files a batch of contrast and labelling bugs, engineering reworks components that were signed off weeks earlier, and the same failing colour pair gets filed five times because five screens use it. The fixes are cheap in Figma and expensive in a shipped component library, which is the wrong way round.

The other failure is a checklist that gets marked complete without recording what was evaluated. A design file genuinely cannot settle whether focus order works, whether a screen reader announces something useful, or whether an animation respects reduced-motion preferences. If a review does not say which criteria it left open, the resulting green tick is the most misleading artifact in the process.

How ZeroTwo audits a design for accessibility

Reads the frames and the design system they draw on — ZeroTwo pulls the frames for the flow under review along with the library styles they reference, so a colour pair or touch target that fails is traced back to the shared token rather than reported once per screen.
Checks the criteria a design can demonstrate — The agent evaluates text and non-text contrast, target size, text spacing and reflow behaviour, visible focus treatment, meaningful sequence, whether meaning is carried by colour alone, and whether interactive elements have accessible names specified.
Separates findings from judgement calls — Measurable failures such as a contrast ratio below threshold are reported as findings with the measured value. Criteria that need real markup or interaction — keyboard traps, screen reader output, motion preferences — are listed as items the design cannot settle, so they reach implementation review instead of being silently marked pass.
Files prioritized remediation tickets — Each finding becomes a ticket naming the frame, the WCAG criterion, the measured value, and the suggested fix, with token-level problems filed once against the design system rather than repeatedly against each screen.
Sends the summary to the feature channel — Designers and engineers get a short digest of what blocks release, what is a token fix, and what still needs manual assistive-technology testing before sign-off.

A design audit is a first pass, and should say so

ZeroTwo treats Figma, Linear, and the review channel as one job: read the frames and their underlying styles, evaluate the criteria a static design can demonstrate, and turn each failure into a ticket that names its evidence. Reading the library alongside the frames is what makes the output useful — it is the difference between reporting a symptom on every screen and reporting the token that causes it.

The boundary is the important part. WCAG conformance is not something a design file can establish, and an agent that reports otherwise is worse than no agent. Keyboard operability, screen reader output, motion preferences, and whether a flow is usable under real assistive technology all require the built product and, for anything that matters, disabled testers. ZeroTwo should clear the mechanical findings and then state plainly which criteria remain unverified, so manual testing is aimed at what actually needs a human.

Frequently Asked Questions

Can AI audit a design for accessibility?

It can audit the part a design file can demonstrate: contrast, target size, text spacing and reflow, visible focus treatment, meaningful sequence, colour-only meaning, and whether accessible names are specified. It cannot establish conformance, because criteria involving keyboard operation, screen reader output, and motion preferences need the built product.

Does this replace manual accessibility testing?

No. It removes the mechanical findings so manual testing is spent on the criteria that need judgement and real assistive technology. Testing with disabled users remains the only way to know whether a flow is genuinely usable.

How does it avoid filing the same issue on every screen?

It reads the design system styles the frames reference, so a failing colour pair or target size is traced to the shared token and filed once against the library rather than repeatedly against each screen that uses it.

Which WCAG version does it check against?

You set the target in the prompt — most teams use WCAG 2.2 Level AA. The agent reports the criterion reference alongside each finding so the ticket is reviewable against whichever version you have adopted.

Which systems should be connected for this workflow?

Figma for the frames and library styles, Linear for remediation tickets, and the Slack channel where the feature team already reviews design work.

Get Started

Sample prompt: When a feature is ready for design review, read its Figma frames and the library styles they use, check text and non-text contrast, target size, focus treatment, colour-only meaning, and accessible names, file a Linear ticket per finding with the WCAG criterion and measured value, group token-level failures into a single design system ticket, and post a summary to the feature channel listing what still needs manual assistive-technology testing.

Runs when a feature is marked ready for design review, or on demand against a Figma page.