A contrast audit used to mean opening a checker, eyedropping two colors, reading a ratio, and repeating that a hundred times across a flow until your afternoon was gone. In 2026 you can run a prioritized contrast audit across a five-screen flow in three minutes, because Stark and Polypane will sweep the screens automatically and a Claude-powered pass will turn the raw failures into a fix list with exact ratios and frame coordinates. The catch, and the reason this lesson names every ratio target explicitly, is that "an AI said it passes" is not a WCAG result. The numbers are the result, and you have to know them - 4.5:1 for normal text, 3:1 for large text and graphical objects, and the new WCAG 2.2 criterion 2.4.11 focus-appearance minimum of 3:1 - to verify what the tools tell you. This lesson runs the three-tool audit, produces a prioritized contrast report with fix coordinates by Figma frame, and leaves you able to defend every ratio in it.

The Audit That Used to Eat an Afternoon

Picture the old way. A five-screen onboarding flow needs an accessibility pass before the Thursday review. You open a contrast checker, eyedrop the body text against its background, get 4.6:1, fine. Eyedrop the secondary text, 3.9:1, fail, note it. Eyedrop the placeholder text, the disabled button label, the helper text under the field, the link color, the icon next to the link, the text on the colored banner. Each one is a few seconds and there are dozens per screen and five screens, and somewhere around screen three your attention frays and you start trusting your eye, which is exactly when you miss the 4.3:1 that needed to be 4.5:1. The work is mechanical, it is high-volume, and it is precisely the kind of thing a human does worse the longer they do it.

This is the ideal AI-assist case, and it is worth being honest about why: contrast is math, the math is well-defined by WCAG, and the failure mode of doing it by hand is fatigue, not lack of skill. When the task is high-volume deterministic computation that humans get tired doing, the tool genuinely wins. The contrast audit is the cleanest example in this whole program of work you should hand to the machine, which is also why it is the first accessibility lesson: it earns trust in the tooling before the harder, more judgment-heavy audits later in the chapter.

The Ratio Targets You Must Know Cold

Before any tool, the numbers. You cannot verify a tool's output if you do not know the targets, and "the AI marked it green" is not a defensible audit result. WCAG 2.2 Level AA contrast requirements come down to a small set of named ratios, and a working designer should know them the way they know the spacing scale.

The Named Ratios

1. 4.5:1 for normal text. Body copy and any text below the large-text threshold must have a contrast ratio of at least 4.5:1 against its background. This is the most common requirement and the one most often failed by light-gray secondary text on white.
2. 3:1 for large text. Text that is at least 24px (or 18.66px / roughly 14pt bold) counts as large and needs only 3:1, because larger letterforms are legible at lower contrast. This is why a big heading can use a lighter gray that body copy cannot.
3. 3:1 for graphical objects and UI components. Under WCAG 1.4.11, the visual boundaries of interactive components and meaningful graphics - the edge of an input field, the bars of a chart, an icon that carries meaning - need 3:1 against adjacent colors. This is the one designers forget, because they think of contrast as a text rule, and it is not.
4. 3:1 for focus appearance (2.4.11). WCAG 2.2 added 2.4.11 Focus Appearance, and a key part of it is that the focus indicator must have at least 3:1 contrast against the colors it is shown over (both the focused and unfocused states of the component's adjacent pixels). A focus ring that is a faint outline on a similar background fails real users who navigate by keyboard, and it fails 2.4.11.

Memorize the shape of it: 4.5:1 for normal text, 3:1 for everything else that matters - large text, graphical objects, and the focus indicator. When a tool reports a failure, you check it against these, and when a tool reports a pass on something it should not have evaluated (like a focus ring it could not see), you know to check it yourself.

The tool finds the failures. The ratios are the result. "An AI said it passes" is a claim, not a WCAG conformance statement - you verify the claim against the named targets, because you are the one who signs the audit.

The Three-Tool Audit Pass

Now the workflow. Three tools, each doing the part it is best at, run across the five-screen flow.

Stark is the in-Figma contrast and accessibility plugin. Run it across the flow to sweep every text-background pair and surface the failures in place, on the frame, where you can see exactly which element fails and by how much. Stark's strength is that it lives in the design file, so the failures come back attached to the actual layers, which is what you need for a fix list with coordinates. It checks text contrast well and increasingly flags non-text contrast too.

Polypane is a browser-based developer tool that audits the rendered result, which catches what a static Figma check cannot: actual focus states, hover states, and the contrast of components as they really render with live CSS. If the flow exists as a prototype or built screen, Polypane's audit catches focus-appearance and component-state failures that a design-file checker is blind to, because those states do not exist in a static frame. Stark and Polypane are complementary: design-file coverage plus rendered-state coverage.

A Claude-powered pass turns the raw output into a prioritized, structured fix list. Feed the failures - the element, the measured ratio, the required ratio, the frame - to Claude with a structured prompt and ask it to produce a prioritized report: group by severity, state each failure as "element X measures Y:1, needs Z:1, on frame F," and order by impact. The model is good at the transformation from raw list to organized report, which is genuine drudgery, and it is where the three-minute claim comes from. What the model is not good at, and what you do not delegate, is deciding the targets or signing off; you verify its numbers against the named ratios.

Prioritizing the Fix List, Because Not All Failures Are Equal

A flat list of forty contrast failures is not actionable; a prioritized one is. The prioritization is a judgment call the audit must make, and it follows impact, not just the size of the ratio gap. Severity ordering runs roughly like this. Highest priority: body text below 4.5:1 that users must read to complete a task, because it blocks comprehension for low-vision users on the critical path. Next: interactive component boundaries and focus indicators below 3:1, because they block keyboard and low-vision users from operating the interface at all. Then: large text and decorative-but-meaningful graphics below 3:1. Lowest: failures on rarely-seen states or non-essential elements.

The reason to prioritize rather than dump is that a fix list engineering will actually act on is one that tells them what to fix first and why it matters, and the why is the user impact, not the abstract ratio. A 4.3:1 body text failure that a million users read on the signup screen outranks a 2.9:1 decorative icon nobody needs to perceive, even though the icon's ratio gap is larger. Prioritization by user impact is the judgment the designer brings on top of the tool's math.

The Artifact: A Contrast Report With Fix Coordinates by Figma Frame

The named artifact is a WCAG 2.2 contrast report with fix coordinates by Figma frame. The coordinates are what make it useful: each failure names the exact frame and the exact element, so the person fixing it - whether that is you or an engineer - goes straight to it without hunting. A report that says "some text has low contrast" is useless; a report that says "Frame: Onboarding-Step-2, element: helper text under Email field, measures 3.8:1, needs 4.5:1, fix: darken to token text-secondary-strong (#5A5A5A) for 4.6:1" is a ticket someone can close.

The report's structure carries the named ratios in every line, which is what makes it defensible: each failure states the measured ratio, the required ratio with its WCAG criterion (1.4.3 for text, 1.4.11 for non-text, 2.4.11 for focus), the frame and element, and a suggested fix that hits the target, ideally as a design-system token so the fix is reusable. When you hand this to engineering or to a skeptical stakeholder, every line is verifiable against the standard, and nobody can wave it away as "the designer thinks it looks low contrast," because it is not opinion, it is the named ratio against the measured one.

The Cases a Single Ratio Cannot Describe

Three situations break the "eyedrop two colors, read one ratio" model, and they are exactly where a careless AI audit ships a failure. Knowing them is part of knowing the ratios.

Text over a gradient or image. When the background varies, a single sampled ratio is meaningless, because the text might pass over the dark end of the gradient and fail over the light end. The audit has to check the worst-case region - the lightest background behind the text - and require the text to meet 4.5:1 across the entire area it overlaps, not at one convenient point. For text over imagery, where the background is content-dependent and could change, the right move is a contrast-protecting mechanism: a scrim, a gradient overlay, or a text-safe panel verified to hold the ratio under any image the area could show. Image-overlaid text without such a mechanism fails regardless of how it looks on the one sample image, because the next image could break it.

Multiple themes. A flow that targets light, dark, and high-contrast themes is three distinct sets of color pairings, and a flow conformant in light can fail in dark where a token pairing inverts. Each theme must be audited, not just the default, or you ship a clean light-theme audit while dark-theme users get failing contrast. The efficient way is to verify the semantic token-to-surface pairings within each theme rather than re-checking every instance, since instances inherit from tokens.

State-dependent elements. The focus indicator is the canonical case: its 2.4.11 contrast is measured against the specific adjacent pixels in both the focused and unfocused states, a comparison that only exists at runtime and changes by state. This is why focus appearance is the criterion most likely to ship with a clean audit attached, and why the runtime tool and the known 3:1 target are non-negotiable parts of the workflow.

Encoding Contrast Into Tokens: Prevention Over Detection

The highest-leverage move is to stop catching contrast failures one at a time and start preventing them in the token system. If your semantic text-color tokens are pre-verified against the surface tokens they pair with - text-primary, text-secondary, and text-on-dark each guaranteed to meet 4.5:1 (or 3:1 for large-text and non-text tokens) against the surfaces they sit on - and components are forbidden from using raw hex, then any correct use of the system is conformant by construction. The focus-indicator token is verified to meet 3:1 against the surfaces it appears over, in every theme.

With contrast encoded in tokens, the audit changes character entirely. Instead of measuring dozens of per-instance failures, you verify the token-to-surface pairings and flag any off-token color, because conformance is now a property of using the system correctly rather than of remembering to check each string. Failures can only enter through off-token color or wrong pairings, which are far fewer and easier to catch. This is the same systematization move that runs through the whole program: a quality that used to depend on per-instance vigilance becomes a property of the system, consumed correctly by both designers and the AI agents that read tokens. Prevention in the tokens scales; detection per instance does not, and the contrast audit is at its best when it is mostly verifying that the system was used rather than hunting failures the system should never have allowed.

Why You Verify the Tool, Not Just Trust It

It is tempting, given how good the tooling is, to treat the green checkmarks as the audit and move on. Do not, for two specific reasons. First, the tools have blind spots: a static Figma checker cannot see a focus ring that only exists at runtime, so a flow can pass Stark and still fail 2.4.11, which is exactly why Polypane is in the workflow. If you ran only the design-file tool and trusted its all-green, you would ship a focus-appearance failure with a clean audit attached. Second, tools occasionally miscategorize: a checker may treat large text as normal text and report a false failure, or treat meaningful graphics as decorative and skip them entirely. Knowing the named ratios is how you catch both the false positives and the false negatives.

This is the same discipline from the rest of the program: the tool does the high-volume work and you supply the understanding it lacks, which here is knowing the targets and the tools' blind spots well enough to verify. The three-minute audit is real, and it is three minutes of tool time plus the judgment to check it, not three minutes of blind trust. A designer who knows the ratios cold turns the tools into a genuine accelerator and signs an audit they can defend. A designer who does not know them is just forwarding green checkmarks and hoping, which is not an accessibility practice.

Putting It to Work This Week

Memorize the ratios first - 4.5:1 normal text, 3:1 large text, 3:1 graphical objects and components, 3:1 focus appearance under 2.4.11 - because everything else depends on them. Then run the three-tool pass on a real five-screen flow: Stark in Figma for the design-file sweep, Polypane on the prototype for the rendered states including focus, and a Claude pass to turn the raw failures into a prioritized report. Prioritize by user impact, not ratio gap. Produce the report with frame coordinates, required ratio and criterion per line, and a token-based suggested fix. Spot-check a sample of the tool's findings against the named ratios yourself, because the audit you sign is the audit you can defend, and the green checkmark is a claim until you have verified it.

Key Takeaways

• Contrast auditing is the cleanest AI-assist case in the program: high-volume deterministic math where the human failure mode is fatigue, not skill, so the tools genuinely win and a five-screen flow can be audited in roughly three minutes.
• Know the named ratios cold: 4.5:1 for normal text, 3:1 for large text (24px or 18.66px bold), 3:1 for graphical objects and UI components under 1.4.11, and 3:1 for the focus indicator under the new WCAG 2.2 criterion 2.4.11 Focus Appearance.
• Run three complementary tools: Stark in Figma for the design-file sweep attached to layers, Polypane on the rendered prototype to catch focus and component states a static check cannot see, and a Claude pass to turn raw failures into a prioritized, structured report.
• Prioritize the fix list by user impact, not ratio gap: body text on the critical path and focus or component-boundary failures outrank larger gaps on decorative or rarely-seen elements, because the why an engineer acts on is user impact.
• The artifact is a WCAG 2.2 contrast report with fix coordinates by Figma frame - each line names the measured ratio, the required ratio and its criterion, the exact frame and element, and a token-based suggested fix, so every line is verifiable and closeable.
• Verify the tools rather than trusting the green checkmarks: a static checker cannot see runtime focus rings (so a flow can pass Stark and fail 2.4.11), and tools miscategorize large text and meaningful graphics; knowing the ratios is how you catch the false positives and false negatives and sign an audit you can defend.