Testing WCAG in Figma Before You Write a Single Line of Code

Introduction

Accessibility Starts in Design - Not in Code

Accessibility isn't a post-development checklist. It's a design decision - and it starts in Figma.

If you're estimating an HTML project from a Figma file and skipping the accessibility audit, you're setting yourself up for rework, scope creep, and frustrated clients. Here's everything you need to catch issues before they cost you.

Every week, developers receive Figma links with beautiful interfaces - pixel-perfect gradients, clever micro-interactions, carefully chosen typography. And almost every week, those same designs contain accessibility issues that will cost hours to fix after the fact.

Low contrast text. Missing focus states. Form labels replaced by placeholder text. Touch targets the size of a fingernail. These aren't edge cases. They're endemic to the way most UI design currently works.

"An accessible design isn't a differently constrained design. It's a better design - for every user, on every device, in every context."

The good news: WCAG compliance is entirely auditable inside Figma, before any code is written. This guide walks you through every principle, every check, and every tool you need to make accessibility part of your estimation and handoff workflow.

The 4 Principles of WCAG - P.O.U.R.

WCAG (Web Content Accessibility Guidelines) is built on four non-negotiable pillars. Every rule in the standard traces back to one of these principles. Understanding them changes how you read a Figma file.

👁️ 1. Perceivable - Can Every User See It?

Information and UI components must be presentable to users in ways they can perceive. This covers contrast ratios, alt text for images, text over gradients, and ensuring color is never the sole means of conveying information.

⌨️ 2. Operable - Can Every User Interact with It?

UI components and navigation must be operable. All interactive elements need visible focus states, logical tab order, minimum touch target sizes of 44×44px, and controls for any animations or auto-advancing content.

🧠 3. Understandable - Can Every User Understand It?

Information and operation of the UI must be understandable. Navigation must be consistent, CTAs must be descriptive, error messages must explain what went wrong, and forms must have visible labels - not just placeholders.

💪 4. Robust - Does It Work Everywhere?

Content must be robust enough to be reliably interpreted by assistive technologies. This means proper heading hierarchy (one H1 per page), ARIA role annotations in Figma, semantic landmark regions, and fully designed component states.

Principle 1 - Perceivable: Color Contrast

Contrast is the single most frequently failed WCAG criterion in real-world designs. Here's what the numbers mean and what to check.

Contrast Ratio Standards

Level	Ratio	Applies To
✕ Fail	2.1:1	Light grey on white - fails AA and AAA
✓ AA Pass	4.5:1	Minimum for normal body text
✓ AAA Pass	7:1	Enhanced standard - maximum readability

Color & Contrast Checklist

[x] Text contrast ≥ 4.5:1 (AA) - Normal body text on any background, including text layered over images or gradients (WCAG 1.4.3)
[x] Large text contrast ≥ 3:1 - Applies to text 18px+ regular weight, or 14px+ bold (WCAG 1.4.3)
[x] UI component contrast ≥ 3:1 - Buttons, input borders, icons, focus rings, and interactive elements against their background (WCAG 1.4.11)
[x] Color is not the only indicator - Error states, required fields, and links must also use icons, underlines, or labels - not just a color change (WCAG 1.4.1)
[x] Placeholder text contrast - Placeholder text in form fields must still pass the 4.5:1 threshold (WCAG 1.4.3)
[x] Disabled state contrast - Disabled elements are exempt from contrast requirements, but must be explicitly marked in the design as intentional (WCAG 1.4.3)

Typography & Readability Checklist

[x] Body text ≥ 16px - Designs that use 12–13px for body copy will fail readability standards and require revision (WCAG 1.4.4)
[x] Line height ≥ 1.5× font size - Tight leading significantly reduces readability for users with dyslexia and cognitive disabilities (WCAG 1.4.12)
[x] No text embedded in images - Text inside images cannot be resized, translated, or read by screen readers (WCAG 1.4.5)
[x] Layout works at 400% zoom - No horizontal scrolling, no content clipping, and no overlap of elements when zoomed (WCAG 1.4.10)

Images & Media Checklist

[x] Alt text annotated for all images - Figma annotations should describe image content; decorative images must be marked as presentational (WCAG 1.1.1)
[x] Icon-only elements have labels - Any icon without visible text must have an annotated accessible name (ARIA label) for screen readers (WCAG 1.1.1)

Principle 2 - Operable: Focus, Navigation & Interaction

A design that only works with a mouse is a design that fails millions of users. Every interactive state must be explicitly designed in Figma - never left to browser defaults.

The Focus State Problem

The most commonly missing design element in Figma handoffs is the focus state. Browsers have default focus rings, but they are frequently overridden with outline: none in CSS - and then nothing replaces them. This leaves keyboard users with no visual indicator of where they are on the page.

Every clickable element in a Figma design needs a purpose-built focus state.

What to Flag in Your Estimation

When reviewing a Figma file, document these as design gaps that require resolution before development begins:

-> Missing focus states on buttons and links
-> Touch targets smaller than 44×44px
-> No error or disabled state designed
-> Form fields missing visible labels
-> Animations with no pause control
-> Links distinguishable only by color
-> Heading hierarchy not established
-> Modal and drawer states undefined

"Catching an accessibility failure in Figma takes 30 seconds. Catching it after development takes 3 hours. Catching it after a client audit takes much longer."

Operable Checklist

[x] Visible focus state on every interactive element - Buttons, links, inputs, dropdowns, modals. The focus ring must have at least 3:1 contrast against adjacent colours (WCAG 2.4.7)
[x] Logical tab order annotated - Use the Focus Orderer plugin or numbered annotations to define the expected keyboard navigation sequence (WCAG 2.4.3)
[x] Touch targets ≥ 44×44px - Especially critical for mobile designs; includes icon buttons, close buttons, and navigation items (WCAG 2.5.5)
[x] Animations have pause/stop controls - Carousels, auto-playing videos, parallax backgrounds, and looping animations require a mechanism to stop or pause (WCAG 2.2.2)
[x] No content flashes more than 3× per second - Rapidly flashing content can trigger seizures in photosensitive users (WCAG 2.3.1)

Principle 3 - Understandable: Clear, Consistent Design

Forms: The Most Commonly Broken Pattern

Forms are where the most Understandable-principle failures occur. The pattern is almost always the same: a beautifully minimal form with light placeholder text, no visible labels, and error states that only change a border color. All three of these are WCAG failures.

Every input field must have a persistent visible label that does not disappear when the user starts typing. Error messages must identify what went wrong and how to fix it. Required fields must be marked in a way that doesn't rely solely on an asterisk color.

Understandable Checklist

[x] All form inputs have a visible label - Placeholder text alone fails this criterion; the label must persist even after the user begins entering data (WCAG 1.3.1)
[x] Error messages are descriptive - "Invalid input" fails; "Please enter a valid email address" passes. Error states must be visible in the Figma design (WCAG 3.3.1)
[x] CTA labels are descriptive - Buttons and links labelled "Click Here" or "Read More" fail; screen readers read these out of context, so each label must stand alone (WCAG 2.4.4)
[x] Navigation is consistent across pages - The position, order, and labelling of navigation elements must not change between pages without user action (WCAG 3.2.3)
[x] Confirmations for destructive actions - Delete, submit, and other irreversible actions must have a confirmation step designed in Figma (WCAG 3.3.4)

Principle 4 - Robust: Semantic Structure

Robust / Semantic Structure Checklist

[x] Heading hierarchy is logical - One H1 per page, followed by H2 -> H3 in order. Headings must not skip levels (WCAG 1.3.1)
[x] Landmark regions annotated - Header, Nav, Main, Footer, and Aside regions should be labelled in Figma using the A11y Annotation Kit so developers implement them correctly (WCAG 1.3.6)
[x] All component states designed - Default, Hover, Focus, Active, Disabled, and Error. States that aren't designed in Figma will be skipped or inconsistently implemented (WCAG 4.1.2)
[x] ARIA roles annotated where needed - Custom components like sliders, accordions, tabs, and carousels need their ARIA role documented alongside the design (WCAG 4.1.2)

The Best Figma Plugins for WCAG Auditing

You don't need to eyeball contrast ratios or count pixels manually. These four plugins cover every WCAG check in this article.

🔌 Stark

The most comprehensive accessibility suite for Figma. Covers color contrast, color blindness simulation (8 types), focus order visualization, and exportable accessibility reports. Premium tier unlocks full audit features.

Contrast Color Blindness Reports

🔌 A11y - Color Contrast Checker

Scans entire frames or selected layers at once and flags every failing contrast pair with WCAG level indicators. The fastest way to do a full-page contrast audit before writing your estimate.

Batch Scan AA / AAA

🔌 Contrast by Able

Quick, lightweight contrast checker. Select two layers and instantly see the ratio plus WCAG pass/fail for AA and AAA. Ideal for checking individual components during the design review process.

Quick Check Lightweight

🔌 A11y Annotation Kit

A design system of annotation components for marking up Figma files with reading order, ARIA roles, landmark regions, and focus order. Essential for producing developer-ready, accessible handoffs.

Annotations Handoff

Browser-Based Tools

Tool	Best For
WebAIM Contrast Checker - webaim.org	Hex value contrast testing
Who Can Use - whocanuse.com	Real-world accessibility impact data
Coolors Contrast Checker - coolors.co	Quick palette contrast checks
Adobe Color - color.adobe.com	Full palette accessibility analysis

Full WCAG Quick-Reference Checklist

#	Check	WCAG Ref	Level
1	Text contrast ≥ 4.5:1	1.4.3	AA
2	Large text contrast ≥ 3:1	1.4.3	AA
3	UI component contrast ≥ 3:1	1.4.11	AA
4	Color not the only indicator	1.4.1	A
5	Alt text on all images	1.1.1	A
6	Icon-only elements have ARIA labels	1.1.1	A
7	Body text ≥ 16px	1.4.4	AA
8	Line height ≥ 1.5× font size	1.4.12	AA
9	No text embedded in images	1.4.5	AA
10	Layout works at 400% zoom	1.4.10	AA
11	Visible focus state designed	2.4.7	AA
12	Logical tab order annotated	2.4.3	A
13	Touch targets ≥ 44×44px	2.5.5	AAA
14	Animations have pause control	2.2.2	A
15	No flashing content > 3×/sec	2.3.1	A
16	All form inputs have visible labels	1.3.1	A
17	Error messages are descriptive	3.3.1	A
18	CTA labels are descriptive	2.4.4	A
19	Navigation consistent across pages	3.2.3	AA
20	Heading hierarchy is logical (1 H1)	1.3.1	A
21	Landmark regions annotated	1.3.6	AAA
22	All component states designed	4.1.2	A
23	ARIA roles annotated on custom components	4.1.2	A
24	Destructive actions have confirmations	3.3.4	AA

Conclusion

Make Accessibility Part of Every Estimate

The next time you receive a Figma link for an HTML project, run through this checklist before writing a single number in your estimate. Identify every missing state, every low-contrast text pair, every label-less form field, and document them explicitly.

This serves two purposes. First, it protects you from scope creep when a client asks why a "simple" page took longer than expected. Second, and more importantly, it starts a conversation about quality - and positions you as a developer who builds things right, not just fast.