How to Use the WCAG 2.2 Contrast Audit Prompt to Fix Tokens Instead of One Off Hex Values

Contrast bugs rarely live in a single button. They live in muted text tokens, ghost borders, and chart gridlines that looked fine on a designer laptop and fail on a pale dashboard wall. The WCAG 2.2 UI Contrast Audit Planner: Text and Non Text Checks, Focus Visible Notes, Fix Order, and a Retest Spreadsheet prompt runs a practical WCAG 2.2 oriented audit: scope, sampling across component states, a findings table, a token first fix order, focus visible notes, and a retest spreadsheet engineers will actually fill.

What the prompt produces

1. A scope statement covering text contrast, non text contrast, and focus visible, plus an explicit out of scope list.
2. A sampling plan across default, hover, focus, disabled, and error states on light and dark backgrounds.
3. A measurement method tied to the tools you named, with confirm gaps instead of fake ratios.
4. A findings table template ready for component, state, hex pairs, ratio, criterion, and severity.
5. A fix order that prefers design token changes over one off hex edits in random files.
6. Focus visible notes in plain language for rings on light and dark surfaces.
7. Retest columns and a definition of done for the audit pass.
8. A stakeholder blurb that avoids fake compliance percentages and certification claims.

How to fill the inputs

SurfaceAndLevel should name the product surface and whether this release targets AA or AAA. Do not mix targets mid audit.

ComponentInventory is your sample set. Buttons, inputs, links, charts, and toasts cover most dashboard pain.

ColorTokens needs real hex pairs when you have them. If a token is missing, leave it blank so the prompt does not invent a passing ratio.

KnownIssues should come from users or a prior audit: muted labels, faint ghost borders, weak gridlines.

Tooling lists Figma plugins, Storybook, axe, and manual keyboard checks so the method section stays realistic.

Reading the example output

The sample is a B2B dashboard aiming at WCAG 2.2 AA with a short token list.

• Scope stays narrow, which keeps the pass shippable before release.
• Findings start as a template with measure blanks, not fabricated pass ratios for tokens that were not measured.
• Fix order raises muted text tokens first, because that change repairs many screens at once.
• The stakeholder blurb refuses certification language, which keeps legal and design aligned.

Tips for better results

• Measure large text exceptions carefully. Weight and size change which threshold applies.
• Fix tokens in the design system library before hunting individual Figma frames.
• Include disabled and error states. They fail more often than default.
• Keyboard test focus rings on both themes before you close the ticket.
• Attach before and after ratios in the retest sheet so regressions are obvious.

Mistakes to avoid

• Do not invent contrast ratios for hex pairs you never measured.
• Do not claim certification or legal safe harbor from a checklist.
• Do not fix one button with a hard coded hex while the token still fails elsewhere.
• Do not skip non text contrast on borders, icons, and chart lines.

Who it is for

Product designers, design system owners, and front end engineers preparing an accessibility pass before release.

Schedule the retest on a build that includes the token release, not on a stale Storybook snapshot. Contrast tickets that pass in Figma and fail in production usually failed because the CSS still pointed at an old custom property.

Photograph failing states with the contrast ratio in the ticket title so triage does not reopen debates about whether the bug is real.

Related PromptDig links

Open the WCAG 2.2 UI Contrast Audit Planner: Text and Non Text Checks, Focus Visible Notes, Fix Order, and a Retest Spreadsheet prompt with your tokens and component list. For more design system prompts, Browse more prompts. If you have a retest sheet that survived a release train, Share a prompt.