This guide walks you through building a repeatable accessibility audit workflow entirely inside Figma — from contrast checks to focus order annotation — in under two hours. By catching issues at the design stage, your team avoids costly developer rework and ships interfaces that meet WCAG 2.2 AA standards from day one.

What You'll Build

  • A structured Figma audit page template you can reuse across every project
  • A contrast and colour-blindness check process using Figma plugins (Able, Stark, or A11y Annotation Kit)
  • An interactive focus order annotation layer that developers can follow directly in the handoff file
  • A reusable accessibility checklist component embedded in your Figma design system
  • A documented pass/fail report frame your team can share with stakeholders

Prerequisites

  • Figma Professional or Organisation plan (free plan works for solo audits, but branching requires paid)
  • The Stark plugin (free tier is sufficient for this guide) or Able (free, open source)
  • The A11y Annotation Kit community file — search Figma Community for the Figma-published version (updated March 2026)
  • Basic familiarity with Figma components and auto-layout
  • A design file you want to audit — one screen is enough to follow along

Step 1: Create a Dedicated Audit Page in Your Figma File

Keep audit work separate from production frames so developers never confuse annotated layers with live components.

How do you set up the audit page?

Duplicate your main design page. Rename the duplicate Accessibility Audit. At the top of the page, add a frame sized 1440 × 200 px labelled Audit Header. Inside it, record the audit date, auditor name, WCAG target level (AA in most cases), and a colour-coded status badge — red for In Progress, amber for Issues Found, green for Passed.

This header becomes your report cover when you export the page as a PDF for client or stakeholder sign-off.

Common pitfall: Auditing directly on the production page creates merge conflicts in branching workflows. Always audit on a copy.

Step 2: Run Automated Contrast Checks with Stark or Able

Colour contrast is the single most common WCAG 2.2 failure. WCAG 2.2 Success Criterion 1.4.3 requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (18 pt regular or 14 pt bold).

Which plugin should you use?

Both Stark and Able check contrast ratios against WCAG 2.2. Stark's free tier adds colour-blindness simulation across eight vision types (deuteranopia, protanopia, tritanopia, and more), which is worth the extra step. Able is fully free and open source — a good choice for teams with budget constraints.

Install your chosen plugin from the Figma Plugin menu. Select a text layer, run the contrast checker, and note the ratio.

WCAG 2.2 Contrast Thresholds (as of 2026)
─────────────────────────────────────────
Normal text (< 18pt regular / < 14pt bold): 4.5:1 minimum
Large text (≥ 18pt regular / ≥ 14pt bold): 3:1 minimum
UI components and graphical objects:        3:1 minimum
Enhanced (AAA) normal text:                 7:1 minimum

What should you do when a layer fails contrast?

Flag it with a sticky note component from the A11y Annotation Kit. Label it FAIL – 1.4.3 and paste the actual ratio (e.g. 2.8:1). Do not change the colour yourself — raise it with the brand or design lead, since contrast fixes often affect your design token palette globally.

Pro tip: Check body copy, placeholder text, disabled states, and icon-only buttons separately. Disabled states are exempt from contrast requirements under WCAG 2.2, but placeholder text is not.

Step 3: Simulate Colour Blindness and Low Vision

Approximately 8% of males have some form of colour vision deficiency. Designing only for full-colour vision excludes a meaningful portion of your users.

How do you run a colour-blindness simulation?

In Stark, select the entire screen frame, open the Vision Simulator panel, and cycle through all eight modes. Screenshot each simulation directly in Figma using the plugin's built-in capture, then paste the screenshots into a dedicated Colour Blindness Review section on your audit page.

Look for these two common failures:

  • Error states that use red alone without an icon or text label
  • Charts or graphs that distinguish data series by colour only

WCAG 2.2 Success Criterion 1.4.1 explicitly prohibits using colour as the only visual means of conveying information.

Step 4: Annotate Focus Order with the A11y Annotation Kit

Focus order defines the sequence a keyboard or screen-reader user navigates through your interface. Getting this wrong breaks the experience for anyone who does not use a mouse — including users on mobile keyboards, power users, and assistive technology users.

Why does focus order matter at the design stage?

Developers default to DOM source order when building focus sequences. If your visual layout differs from a logical reading sequence — common in card grids, modals, and sticky headers — the default DOM order produces a broken experience. Annotating at the design stage gives developers an explicit instruction rather than a guess.

Copy the A11y Annotation Kit from Figma Community into your file. Use the numbered focus indicator stickers from the kit. Place sticker 1 on the first interactive element, increment through the screen in logical reading order, and finish at the last actionable element.

For modals and overlays, annotate the focus trap boundary — mark where focus enters the overlay, where it cycles within it, and where it returns on close.

Focus Order Annotation Pattern
──────────────────────────────
1 → Skip to main content link (visually hidden, first in DOM)
2 → Global navigation – logo link
3 → Global navigation – primary links (left to right)
4 → Search input
5 → First main content interactive element
...continue per screen

Common pitfall: Forgetting to annotate a skip-to-content link. WCAG 2.2 Success Criterion 2.4.1 requires a mechanism to bypass repeated navigation blocks. Add this as item 1 in every focus order annotation.

Step 5: Check Touch Target Sizes for Mobile Screens

WCAG 2.2 introduced Success Criterion 2.5.8 (Target Size – Minimum) as a new AA requirement. Interactive targets must be at least 24 × 24 CSS pixels, with recommended best practice at 44 × 44 px (aligned with Apple HIG and Android Material You guidelines).

How do you audit touch targets in Figma?

Switch to your mobile frame. Select each interactive element — buttons, icon buttons, checkboxes, toggle switches, links within body copy — and check the W and H values in the design panel. Any element below 44 × 44 px should be flagged.

Add a sticky note annotation using the A11y kit labelled FAIL – 2.5.8 and note the current size (e.g. 32 × 32 px). For icon-only buttons, the visible icon can be smaller than 44 px as long as the invisible tap target area (hit area) meets the threshold — annotate this distinction clearly for developers.

Pro tip: Create a shared component in your design system called Touch Target Wrapper — a 44 × 44 px transparent bounding box that wraps small icons. This solves the problem systemically rather than case by case.

Step 6: Audit Text Alternatives and Semantic Labelling

Screen readers cannot interpret images, icons, or custom illustrations without text alternatives. This step bridges the gap between your visual layer and the semantic HTML a developer will write.

What needs a text alternative?

Every non-text element that conveys meaning needs an alt text annotation. Purely decorative images should be marked as presentational (alt=""). Use the A11y kit's label sticker to annotate each image, icon, and illustration with its intended alt text or role.

For form fields, annotate the visible label, the input type, any placeholder text, and whether the field is required. This maps directly to the HTML label, type, placeholder, and required attributes — reducing ambiguity during developer handoff.

At Lenka Studio, this annotation layer is a required deliverable in every design handoff file. It cuts average developer QA time on accessibility by roughly 30% because the semantic intent is explicit before the build starts.

Step 7: Compile the Pass/Fail Report Frame

Stakeholders need a clear summary. A verbose annotation page is useful for developers but not for a product owner, a legal team, or a client in Australia asking whether the product meets the Disability Discrimination Act 1992 requirements.

How do you structure the report frame?

Create a new frame at the bottom of your audit page. Use an auto-layout table with these five columns: WCAG Criterion, Level, Description, Status, and Location. Populate one row per finding. Use component variants for the status badge — green for Pass, amber for Needs Review, red for Fail.

Export the full audit page as a PDF (File → Export → Page as PDF in Figma). This becomes your formal accessibility report — a shareable artefact that satisfies procurement requirements and third-party auditors.

Teams at companies in Canada and Singapore increasingly require this format to satisfy emerging government digital accessibility mandates (Canada's Accessible Canada Act, Singapore's Digital Service Standards 3.0).

Step 8: Build a Reusable Audit Template for Future Projects

Running this workflow once is useful. Running it on every project without rebuilding it each time is what makes it a real system.

How do you turn the audit page into a reusable template?

Once your audit page is complete and all components are from your local library, save it as a Figma Community file or a private team template. Include the audit header, the contrast check section, the focus order annotation section, the touch target checklist, the text alternatives table, and the pass/fail report frame.

Add a Checklist component at the top of the template listing all eight steps from this guide. Auditors tick each item as they go. This takes roughly five minutes to set up per new project and standardises quality across your entire design team.

If your design system lives in a separate Figma file, link the accessibility checklist component back to it using Figma's library publish feature so it updates everywhere when WCAG guidance changes.

Frequently Asked Questions

Does this workflow cover WCAG 2.2 AA fully?

This workflow covers the most common AA failures that are detectable at the design stage. Some criteria — like keyboard operability (2.1.1) and timing adjustments (2.2.1) — require coded prototypes or live testing with assistive technologies such as NVDA, VoiceOver, or JAWS.

Is Stark free enough for a small team?

Stark's free tier includes contrast checking and colour-blindness simulation for up to three projects per month, which is sufficient for this tutorial. For larger teams running multiple audits weekly, Stark's Team plan (as of 2026) is around USD 60/month and adds bulk scanning and an issue tracker.

How is this different from running a WAVE or axe audit on the live site?

Automated browser tools like WAVE and axe audit the built HTML and CSS — they catch roughly 30–40% of WCAG issues in code. This Figma workflow catches design-layer issues before development begins, so colour, layout, focus order, and labelling problems are resolved at zero engineering cost.

What if our brand colours fail contrast checks?

Raise it as a design token issue rather than a one-off fix. Update the token value (e.g. color.text.secondary) in your design system and republish the library. This propagates the fix to every component that uses that token across all files — a systemic solution rather than a manual patch.

Does this workflow apply to dark mode designs too?

Yes, and dark mode is often where contrast failures hide. Run Steps 2 and 3 on both light and dark mode frames separately. Dark backgrounds with light text invert contrast relationships, and some colours that pass in light mode fail in dark mode — especially mid-range greys and muted brand colours.

Next Steps

You now have an eight-step accessibility audit workflow you can run on any Figma file in under two hours. Start by auditing one existing screen this week — even a single pass often surfaces three to five fixable issues before any code is written.

To go further, consider integrating axe DevTools into your CI/CD pipeline so automated contrast and ARIA checks run on every pull request alongside your Figma audits. That combination — design-stage and code-stage checks — is the most robust accessibility process available as of 2026.

If you want to embed this kind of structured quality process across your whole product — from design system architecture to developer handoff — the team at Lenka Studio works with SMBs in Australia, Singapore, Canada, and the US to build design systems and workflows that scale. Get in touch and we can walk through what this looks like for your team.