Accessibility Audit: From HTML Audit to Figma Redesign

Why Start the Accessibility Redesign in Figma?

Accessibility remediation typically follows one of two paths: fix directly in code (fast for isolated issues like missing alt text) or redesign in Figma and hand off to developers (necessary when failures are visual and systemic — contrast, focus indicators, component structure, touch target sizing).

The Figma path makes sense when:

• Multiple components fail the same criterion and need a consistent fix (e.g., all buttons have insufficient contrast — the solution is a new color token, not 40 individual code patches)
• The fix changes the visual design (contrast, spacing, focus ring styling) and needs designer review before developer implementation
• You need annotated specs for a development team that won't make design decisions independently
• Stakeholder sign-off on the accessible design is required before code remediation begins

The challenge: your Figma file probably doesn't match the live implementation. You'd be redesigning against an approximation. Importing the actual failing HTML into Figma with html2design gives you the real implementation as your starting point — every pixel, every color, every font value exactly as it exists in production.

Step 1: Run the Accessibility Audit

Automated tools catch approximately 30–40% of WCAG failures — the rest require manual review. Start with automation to get a prioritized issue list, then supplement with manual checks.

Automated audit tools

• axe DevTools — Browser extension that runs a WCAG audit on the active page. Shows violations with element selectors, WCAG criterion reference, and suggested fixes. Free tier available; best in class for automation coverage.
• WAVE — WebAIM's accessibility evaluation tool. Overlays icons directly on the page marking errors, alerts, and structural elements. Good for visual-first audits.
• Chrome Lighthouse — Built into DevTools → Lighthouse tab → Accessibility audit. Produces a scored report with specific WCAG references. Fast for initial triage.
• IBM Equal Access Checker — Good complement to axe for catching different issue subsets, especially for IBM Design Language patterns.

Manual checks to add

• Keyboard navigation — Tab through every interactive element. Does focus move in logical order? Is focus always visible? Can everything be activated with Enter/Space?
• Screen reader test — Run VoiceOver (macOS) or NVDA (Windows) and navigate to key sections. Listen for missing labels, confusing announcements, or interactive elements that aren't announced correctly.
• Zoom test — Set browser zoom to 200% (WCAG 1.4.4). Does content reflow correctly? Does text truncate, overlap, or lose functionality?
• Motion sensitivity — Check for auto-playing animations. WCAG 2.3.3 (AAA) and 2.2.2 (AA) address motion; verify there's a pause/stop mechanism for anything that moves for more than 5 seconds.

Step 2: Prioritize Failures for Figma Redesign

Not every audit failure needs a Figma redesign. Triage your findings:

Focus your Figma work on issues that require visual design decisions: contrast, focus styles, touch targets, and color-as-information patterns. These are the issues where a Figma redesign and annotated spec is genuinely useful to developers.

Step 3: Import Failing Sections into Figma

Step 4: Redesign for Compliance in Figma

With the live implementation as your Figma baseline, you can now redesign precisely for each WCAG criterion.

Color contrast (WCAG 1.4.3)

WCAG 2.1 Level AA requires 4.5:1 contrast for normal text and 3:1 for large text (18pt+ or 14pt+ bold). In your imported Figma frame, select a text layer. Open the Stark or Contrast plugin — it reads the fill color and background fill and calculates the ratio instantly. Adjust the text color or background fill until the ratio passes. Record the passing color pair in a Figma annotation beside the frame.

For teams on a design token system: this is the moment to update the token, not just the one instance. If your text-muted color fails contrast, every component that uses it needs the fix. Update the Figma Color Variable (or Style) and watch all component instances update automatically.

Focus indicators (WCAG 2.4.7 and 2.4.11)

The most common focus indicator failure: the browser default outline was removed with outline: none and nothing replaced it. In Figma:

1. Select the button, input, or link in the imported frame.
2. Add a stroke to the shape using the Stroke property in Figma. Choose a color with 3:1 contrast against the background (WCAG 2.4.11 minimum area requirement).
3. If the element has a rounded background, make the focus ring a slightly larger rectangle with a gap — matching the WCAG 2.2 "focus appearance" model (2px minimum, offset by 2px).
4. Create the focus state as a Figma Component Variant so developers see both default and focused states.

Touch target sizing (WCAG 2.5.8)

WCAG 2.2 Success Criterion 2.5.8 (Level AA) requires interactive targets to be at least 24x24 CSS pixels (upgraded from the older 44x44px WCAG 2.5.5 AAA guideline, though 44x44px remains best practice for mobile). In Figma:

1. Select the interactive element in the imported frame.
2. Check its dimensions in the Figma layout panel. If under 44x44px (or 24x24px at minimum), annotate it with a red overlay rectangle showing the minimum size requirement.
3. In the fixed state frame, show the element with sufficient padding or explicit min-width/min-height to meet the target.

Color as sole information indicator (WCAG 1.4.1)

Patterns that fail this criterion: error states shown only in red (no error icon or text), status badges where the label is color-only (a green badge says "active," a red one says "error," but the text inside is the same), required form fields marked only with a colored asterisk.

In Figma, redesign to add a second visual cue: an icon, a text label, a shape change, or an underline. The test is: if you convert the design to grayscale, does the same information remain conveyed? If yes, WCAG 1.4.1 passes.

Step 5: Annotate the Figma File for Developer Handoff

The goal of the Figma annotation is unambiguous developer instructions — specific enough that the developer doesn't need to make design decisions during implementation.

Standard accessibility annotation elements in Figma:

• Numbered focus order circles — Place a circle with a number on each interactive element showing the expected tab order. Use a consistent annotation component so numbers are visually distinct from the design.
• ARIA label callouts — For icons, icon buttons, and elements where the visible label differs from the accessible name, add a text annotation: "aria-label: 'Close modal'" beside the element.
• Heading level indicators — Mark H1, H2, H3 in the Figma layer for each heading element. Developers can verify the visual hierarchy matches the semantic hierarchy.
• Error state annotations — Show the error state variant with the error message text, error icon, and aria-describedby association labeled explicitly.
• Contrast ratio callouts — For each text/background pair, annotate the passing contrast ratio and the hex values used. "Text: #1F2937, Background: #FFFFFF, Contrast: 16:1 (AA ✓)"

Step 6: Review and Ship the Remediation

Before handing off the Figma file:

1. Designer review — Verify the fixed design still meets brand and aesthetic standards. Accessibility fixes shouldn't look like afterthoughts — they should feel native to the design system.
2. Check with a screen reader — Test the key user flows with VoiceOver or NVDA before the developer implements the fix, so you catch annotation gaps before code is written.
3. Validate contrast with a plugin — Run Stark or Contrast on the fixed state frames in Figma. Every text/background combination should show a passing ratio.
4. Post-implementation audit — After the developer implements the fix, re-run axe DevTools on the live page. The fixed criterion should no longer appear in the violations list.

Frequently Asked Questions

How do I design accessible components in Figma?

Import the live non-compliant component with html2design to get the real implementation as a Figma baseline. Duplicate the frame, then redesign for the specific WCAG criteria that failed: adjust colors for contrast, add focus indicator styles, increase touch target padding. Use Figma accessibility plugins (Stark, Contrast, Able) to validate the redesign before handoff.

What WCAG level should I target?

WCAG 2.1 Level AA is the standard required by most accessibility regulations globally — including the European EN 301 549, Section 508 in the US, and WCAG 2.2 AA (which supersedes 2.1 AA with minor additions). Targeting AA is both the legal baseline and a meaningful accessibility improvement for users. Level AAA is aspirational and not required for compliance — include AAA criteria where achievable without significant design compromise.

Can Figma designs be accessibility-checked before developers build them?

Yes — use Stark, Contrast, or Able plugins to check contrast ratios and simulate color blindness directly in Figma. These plugins cover the visual layer of accessibility. Semantic, keyboard, and screen reader accessibility can't be fully validated in Figma — that requires testing the live HTML. The Figma audit catches visual failures early; the code audit catches structural failures after implementation.