EAA Compliance Checklist for Designers — WCAG 2.2 in Figma
Article updated June 2025 — European Accessibility Act in force
The European Accessibility Act (EAA) entered into force in June 2025. If your client is a company selling digital products or services in Europe (e-commerce, banking services, transport, media, telecommunications), their interfaces must be accessible according to the EN 301 549 standard, which is based on WCAG 2.1 AA and integrates the new features of WCAG 2.2.
This article gives you a practical checklist of WCAG 2.2 AA criteria to verify at the Figma mockup stage, with the right tools for each verification.
Who is affected by the EAA?
Section titled “Who is affected by the EAA?”The EAA applies to companies that sell products or services in the following categories, provided they have more than 10 employees or more than €2M in revenue:
- Consumer banking and financial services
- E-commerce (online sale of products and services)
- Transport (booking and ticketing websites and apps)
- Audiovisual services (streaming platforms, VOD)
- E-books and e-readers
- Telephony and communications services
Exemptions: Micro-enterprises (< 10 employees AND < €2M revenue) are explicitly exempt from EAA requirements for services. SMEs can also invoke disproportionate burden, but must justify it.
Note for the US market: While the EAA is a European law, US companies selling to European customers are also affected. Additionally, the Americans with Disabilities Act (ADA) has been consistently interpreted by courts to require WCAG 2.1 AA compliance for websites and apps serving US customers.
Why check accessibility in Figma rather than in development?
Section titled “Why check accessibility in Figma rather than in development?”Fixing an accessibility issue in a Figma mockup costs 50 to 100 times less than a fix on the developed and deployed application. Case studies from large companies (Microsoft, BBC, Airbnb) consistently show that integrating accessibility from the design stage (Design for Accessibility) reduces total compliance cost by 30 to 70%.
Furthermore, contrast, target size, or heading hierarchy violations are visible in Figma — they are often invisible in code if not flagged to the developer.
The 10 most frequently violated WCAG 2.2 AA criteria in Figma mockups
Section titled “The 10 most frequently violated WCAG 2.2 AA criteria in Figma mockups”1. Insufficient text contrast (SC 1.4.3)
Section titled “1. Insufficient text contrast (SC 1.4.3)”By far the most common violation. The criterion requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (≥ 18pt or ≥ 14pt bold).
How to check in Figma: Use A11y Audit — WCAG 2.2. Select your frame and run the audit. All text contrast violations are flagged with the measured ratio and the required ratio. Full guide →
Typical errors: light gray text on white background, white text on insufficiently dark bright background, placeholder text too faint.
2. Insufficient UI component contrast (SC 1.4.11)
Section titled “2. Insufficient UI component contrast (SC 1.4.11)”Form field borders, informational icons, and active component states must have a contrast ratio of at least 3:1 against their background.
How to check in Figma: A11y Audit detects component outlines with insufficient contrast. For icons, verify their color achieves a ratio ≥ 3:1 on the background.
Typical error: input field with #CCCCCC border on white background = 1.6:1 ratio, far too low.
3. Touch target too small (SC 2.5.8 — new in WCAG 2.2)
Section titled “3. Touch target too small (SC 2.5.8 — new in WCAG 2.2)”Introduced in WCAG 2.2, this criterion requires interactive elements to have a click/tap area of at least 24×24 CSS pixels. The enhanced criterion (2.5.5, AAA level) requires 44×44 px.
How to check in Figma: A11y Audit measures the dimensions of interactive elements. Pay particular attention to navigation icons, action buttons, and text links on mobile.
Typical error: 16×16 px icons in a mobile navigation bar.
4. Insufficient focus visible (SC 2.4.11 — new in WCAG 2.2)
Section titled “4. Insufficient focus visible (SC 2.4.11 — new in WCAG 2.2)”Introduced in WCAG 2.2, this criterion requires the keyboard focus indicator to be visible and sufficiently contrasted. It requires a contrast ratio of at least 3:1 between the focus indicator colors and the background colors, and a minimum focus indicator area.
How to check in Figma: Explicitly create “focus” states for your interactive components. Use a minimum 3px outline or a contrasted focus ring.
Typical error: Component with no ":focus" state defined in the Figma library — the developer will implement the browser default style, which is often insufficient.
5. Information conveyed by color alone (SC 1.4.1)
Section titled “5. Information conveyed by color alone (SC 1.4.1)”If you use color to indicate a state (error in red, success in green, required field in orange), you must also provide a non-color indicator (icon, text, pattern).
How to check in Figma: Enable the color blindness simulator (protanopia/deuteranopia) in Figma or in A11y Audit. Verify that information remains understandable.
Typical error: Bar chart with data series differentiated only by color, without label or pattern.
6. Images without text alternative (SC 1.1.1)
Section titled “6. Images without text alternative (SC 1.1.1)”Every informational image must have a text equivalent. In Figma, this translates to descriptive layer naming for all images that are not purely decorative.
How to check in Figma: A11y Audit flags image layers with generic names. Name your layers descriptively or prefix them [deco] for decorative images.
7. Inconsistent heading hierarchy (SC 1.3.1)
Section titled “7. Inconsistent heading hierarchy (SC 1.3.1)”The H1 > H2 > H3 structure must be logical and without level skips. Heading hierarchy is the primary navigation tool for screen reader users.
How to check in Figma: Apply text styles named Heading/H1, Heading/H2, etc. A11y Audit analyzes the order of appearance of these styles in the frame and flags inconsistencies.
8. Same links pointing to different destinations (SC 2.4.6)
Section titled “8. Same links pointing to different destinations (SC 2.4.6)”If two links have the same label but point to different destinations, that’s a violation. Conversely, if the same content is accessible from two places, both links must have the same label.
How to check in Figma: Manual review. Go through your mockup’s links and verify label consistency.
9. Forms without associated labels (SC 1.3.1 and 4.1.2)
Section titled “9. Forms without associated labels (SC 1.3.1 and 4.1.2)”Each form field must have an explicit visible label. Placeholders do not replace labels (they disappear on input).
How to check in Figma: Verify that each form field in your mockup has a label positioned above or to the left of the field, visible at all times.
10. Content that doesn’t reflow at 400% zoom (SC 1.4.10)
Section titled “10. Content that doesn’t reflow at 400% zoom (SC 1.4.10)”Content must be accessible without horizontal scrolling up to 400% zoom (on a 1280 px wide window, this corresponds to 320 CSS pixels).
How to check in Figma: Create a 320 px wide frame and adapt your layout to it. If content doesn’t fit without horizontal scrolling at 320 px, there’s a responsive design issue to anticipate.
Summary table
Section titled “Summary table”| WCAG Criterion | How to check in Figma | Tool |
|---|---|---|
| 1.4.3 Text contrast | Automatic audit | A11y Audit |
| 1.4.11 UI contrast | Automatic audit | A11y Audit |
| 2.5.8 Target size | Automatic audit | A11y Audit |
| 1.1.1 Alternative text | Audit + layer naming | A11y Audit |
| 1.3.1 Heading hierarchy | Audit + text styles | A11y Audit |
| 1.4.1 Color only | Color blindness simulator | Figma native |
| 2.4.11 Focus visible | Manual component review | Manual |
| 2.4.6 Link labels | Manual review | Manual |
| 1.3.1 Form labels | Manual review | Manual |
| 1.4.10 Reflow 400% | 320px frame | Figma native |
Integrating accessibility into your design workflow
Section titled “Integrating accessibility into your design workflow”Here are the practical steps to integrate WCAG compliance into your design process:
From the very start of brand design: Verify that your color palette respects contrast ratios. It’s much harder to fix colors once the brand is signed off by the client.
At every mockup iteration: Run an A11y Audit audit at each sprint delivery. Include the compliance score in your delivery report.
Before final delivery to the client: Generate the complete PDF report. Deliver it to the development team with violations and correction recommendations.
After development: Recommend to your client a final application audit using testing tools (axe DevTools, WAVE, screen readers).
Business case for accessibility
Section titled “Business case for accessibility”Accessibility isn’t just a legal requirement: accessible websites on average have better user experience for everyone, better organic search ranking (Google values semantic structure and alt texts), and lower mobile bounce rates.
Studies show that people with disabilities represent approximately 15% of the global population (WHO data), translating to significant purchasing power. Additionally, accessible designs benefit all users: captions help in noisy environments, high contrast helps in bright sunlight, large touch targets help elderly users.
Conclusion
Section titled “Conclusion”The EAA creates a new baseline for digital products in Europe. As a designer, you’re in the best position to prevent accessibility issues before they reach development — and a structured audit at the mockup stage is the most cost-effective way to do it.
Start today by installing A11y Audit — WCAG 2.2 and auditing your next Figma mockup.