Accessibility Auto-Audit

An accessibility auto-audit uses a vision model to inspect design frames for likely WCAG failures before engineering builds the UI. The model looks at visible layout, color, typography, and control affordances, then produces a prioritized list of candidate violations with enough context for a designer to verify and fix them.

The audit is a screening pass, not a certification. It flags patterns that commonly fail contrast, non-text contrast, focus visibility, touch target size, and missing or ambiguous labels. It does not prove conformance, and it does not replace keyboard testing, screen-reader checks, or legal review.

Tools such as Stark already cover many rule-based checks inside design tools. A vision-led audit complements those plugins when you want a narrative remediation backlog across whole frames or flows, including issues that are easier to spot from a rendered composition than from isolated color swatches. Use both: automated color and annotation helpers for precision, and a frame-level scan for coverage and prioritization.

Related design-stage work sits nearby. Contract clarity for APIs is covered in API Contract Generator. Interaction quality judgment is covered in Heuristic Design Critique. Evidence from research sessions is covered in Usability Feedback Synthesizer. Accessibility auto-audit is the quality gate that asks whether the visual design is usable for people who rely on assistive technology or non-default perception.

Run the audit when frames are stable enough to represent the intended UI, not while exploration is still rearranging every screen. Good triggers include design review before stakeholder sign-off, pre-handoff QA, and regression checks after a visual refresh or design-system update.

Early wireframes with placeholder gray boxes waste the model’s attention and produce noisy results. Mid-fidelity screens with real copy, final-ish color, and defined interactive states are the sweet spot: the model can evaluate contrast and labeling without pretending unfinished exploration is production UI.

Re-run after material visual changes: new brand palette, denser tables, dark-mode variants, or redesigned form patterns. A one-time scan at the start of a project does not protect later iterations. Treat the audit like lint for accessibility: cheap to repeat, expensive to skip until engineering or production users find the same issues.

Do not use the audit as a substitute for including accessibility criteria in acceptance criteria. The output is an input to remediation planning. Design still owns the fix list, and engineering still owns implementation verification in the built product.

Provide rendered design frames or exports that show the UI as a user would see it. Frame selection should be explicit: primary flows, error and empty states, modals, and any theme variants that change contrast. If the request points at a file, page, or selection that contains no design frames (or only empty artboards), return empty output. Do not invent screens, do not invent issues, and do not pad the response with generic WCAG advice. Empty frames mean empty results.

Useful accompanying context, when available, includes the target WCAG level (often AA for product UI), known exceptions already accepted by the team, component library tokens, and which frames are prototypes versus production-bound. Without that context, the model should still flag clear visual risks, but it should mark uncertain findings as needing human confirmation rather than stating them as definitive failures.

Stark and similar plugins remain useful for numeric contrast ratios and annotation. The vision audit should cite the frame, the element or region, the suspected criterion family (for example contrast of text, contrast of UI components, focus appearance, target size, or name/role/value cues visible in the design), and a concrete remediation suggestion. Prefer actionable language (“increase body text contrast against this background” or “enlarge the primary icon button hit area”) over criterion numbers alone.

If multiple themes exist, audit each theme separately. A light-mode pass does not clear dark mode. If only one theme is supplied, say so in the output so reviewers do not assume coverage they did not get.

The model should group findings by severity and user impact, not by the order frames appear in the file. Prioritize issues that block reading, identifying controls, or completing a task: insufficient text contrast on primary content, controls that disappear into the background, focus indicators that are invisible against the canvas, and interactive targets that are too small to hit reliably.

Secondary findings include decorative contrast risks, dense icon-only toolbars without visible labels or tooltips in the design, and inconsistent focus or selection treatments across a flow. Keep speculative items short and labeled as speculative. If the design does not show keyboard focus states, the model can note the absence as a coverage gap rather than inventing a failing focus ring.

Each item in the remediation list should be self-contained: frame name, approximate location, what looks wrong, why it matters for users, and a suggested fix path. Avoid dumping raw WCAG text. Designers need a backlog they can triage in a review, not a standards dump.

When the same pattern repeats (for example every secondary button fails contrast), collapse duplicates into a pattern-level finding with examples. Pattern findings reduce noise and push teams toward token or component fixes instead of one-off patches.

The model flags candidates. Design remediates. A human must confirm whether a flagged region is true content, a placeholder, or an intentional brand exception already documented. A human chooses the fix: adjust tokens, change type weight, add a visible label, enlarge a target, or redesign the pattern. A human decides whether a finding is deferred, accepted with rationale, or fixed before handoff.

Keep the loop short. Designer or accessibility reviewer runs the scan, verifies the top-priority items against the frames, applies fixes in the design tool, and re-runs on the changed frames. Do not treat a clean second scan as proof that the product is accessible. Built UI introduces CSS, focus management, and dynamic states that design frames cannot fully represent.

Ownership also includes knowing when to stop trusting vision alone. Charts, maps, video players, and complex custom widgets often need specialist review. Motion and flashing content need separate checks. Content that is not yet in the design (live data, error copy from the backend) is out of scope for this audit and should be noted as uncovered.

Vision models misread small text, over-count decorative elements as controls, and under-detect issues that only appear under keyboard or assistive-technology use. They cannot measure true pixel ratios as reliably as purpose-built contrast tools, and they cannot hear how a screen reader announces a control. Use Stark or equivalent for precise color math when a finding hinges on a ratio. Use the vision audit for breadth, prioritization, and narrative remediation across frames.

Never ship on “the audit found nothing” alone. Empty findings on a fully populated set of frames mean no high-confidence visual candidates were produced, not that WCAG is satisfied. Missing frames must produce empty output so teams do not mistake silence for a pass. Partial frame sets should be labeled as partial so reviewers know what was never inspected.

Used this way, accessibility auto-audit is a design-stage quality practice: fast screening, explicit human remediation, and honest empty results when there is nothing real to evaluate.