Checklist EAA pour les designers — WCAG 2.2 AA dans Figma

Article mis à jour en juin 2025 — European Accessibility Act en vigueur

L’European Accessibility Act (EAA) est entré en vigueur en juin 2025. Si votre client est une entreprise qui vend des produits ou services numériques en Europe (e-commerce, services bancaires, transport, médias, télécommunications), ses interfaces doivent être accessibles selon la norme EN 301 549, qui s’appuie sur WCAG 2.1 AA et intègre les nouveautés de WCAG 2.2.

Cet article vous donne une checklist pratique des critères WCAG 2.2 AA à vérifier dès la phase de maquette Figma, avec les outils adaptés à chaque vérification.

Qui est concerné par l’EAA ?

L’EAA s’applique aux entreprises qui commercialisent des produits ou services dans les catégories suivantes, dès lors qu’elles ont plus de 10 salariés ou plus de 2 M€ de chiffre d’affaires :

Services bancaires et financiers aux consommateurs
Commerce électronique (vente en ligne de produits et services)
Transport (sites et applications de réservation, billetterie)
Services audiovisuels (plateformes de streaming, VOD)
Livres numériques et liseuses
Téléphonie et services de communication

Exemptions : Les micro-entreprises (< 10 salariés ET < 2 M€ de CA) sont explicitement exemptées des exigences EAA pour les services. Les PME peuvent également invoquer une charge disproportionnée, mais doivent le justifier.

Secteur public français : le secteur public est soumis au RGAA (Référentiel Général d’Amélioration de l’Accessibilité), qui prédate l’EAA et s’applique indépendamment de celui-ci.

Pourquoi vérifier l’accessibilité dans Figma plutôt qu’en développement ?

Corriger un problème d’accessibilité dans une maquette Figma coûte 50 à 100 fois moins cher qu’une correction sur l’application développée et déployée. Les études de cas de grandes entreprises (Microsoft, BBC, Airbnb) montrent systématiquement que l’intégration de l’accessibilité dès la conception (Design for Accessibility) réduit le coût total de conformité de 30 à 70 %.

De plus, les violations de contraste, de taille de cible ou de hiérarchie de titres se détectent visuellement dans Figma — elles sont souvent invisibles dans le code si elles ne sont pas signalées au développeur.

Les 10 critères WCAG 2.2 AA les plus fréquemment violés dans les maquettes Figma

1. Contraste insuffisant du texte (SC 1.4.3)

C’est de loin la violation la plus fréquente. Le critère exige un rapport de contraste d’au moins 4.5:1 pour le texte normal et 3:1 pour le grand texte (≥ 18pt ou ≥ 14pt en gras).

Comment vérifier dans Figma : Utilisez A11y Audit — WCAG 2.2. Sélectionnez votre frame et lancez l’audit. Toutes les violations de contraste texte sont signalées avec le ratio mesuré et le ratio requis. Guide complet →

Erreurs typiques : texte gris clair sur fond blanc, texte blanc sur fond de couleur insuffisamment sombre, textes de placeholder trop pâles.

2. Contraste insuffisant des composants UI (SC 1.4.11)

Les bordures de champs de formulaire, les icônes informatives et les états actifs des composants doivent avoir un rapport de contraste d’au moins 3:1 par rapport à leur arrière-plan.

Comment vérifier dans Figma : A11y Audit détecte les contours de composants trop peu contrastés. Pour les icônes, vérifiez que leur couleur a un ratio ≥ 3:1 sur l’arrière-plan.

Erreur typique : champ de saisie avec bordure #CCCCCC sur fond blanc = ratio 1.6:1, très insuffisant.

3. Taille de cible tactile trop petite (SC 2.5.8 — nouveau en WCAG 2.2)

Introduit dans WCAG 2.2, ce critère exige que les éléments interactifs aient une zone de clic/tap d’au moins 24×24 pixels CSS. Le critère renforcé (2.5.5, niveau AAA) exige 44×44 px.

Comment vérifier dans Figma : A11y Audit mesure les dimensions des éléments interactifs. Vérifiez particulièrement les icônes de navigation, les boutons d’action et les liens texte sur mobile.

Erreur typique : icônes de 16×16 px dans une barre de navigation mobile.

4. Focus visible insuffisant (SC 2.4.11 — nouveau en WCAG 2.2)

Introduit dans WCAG 2.2, ce critère exige que l’indicateur de focus clavier soit visible et suffisamment contrasté. Il faut un rapport de contraste d’au moins 3:1 entre les couleurs de l’indicateur de focus et celles de l’arrière-plan, et une surface minimale de l’indicateur.

Comment vérifier dans Figma : Créez explicitement des états “focus” pour vos composants interactifs. Utilisez un contour de 3px minimum ou un outshine contrasté.

Erreur typique : Composant sans état ":focus" défini dans la bibliothèque Figma — le développeur implémentera le style par défaut du navigateur, souvent insuffisant.

5. Information transmise uniquement par la couleur (SC 1.4.1)

Si vous utilisez la couleur pour indiquer un état (erreur en rouge, succès en vert, champ obligatoire en orange), vous devez également fournir un indicateur non-colorimétrique (icône, texte, motif).

Comment vérifier dans Figma : Activez le mode simulateur de daltonisme (protanopie/deutéranopie) dans Figma ou dans A11y Audit. Vérifiez que l’information reste compréhensible.

Erreur typique : Graphique à barres avec des séries différenciées uniquement par la couleur, sans label ni motif.

6. Images sans texte alternatif (SC 1.1.1)

Toute image informative doit avoir un équivalent textuel. Dans Figma, cela se traduit par un nommage de calque descriptif pour toutes les images qui ne sont pas purement décoratives.

Comment vérifier dans Figma : A11y Audit signale les calques image avec des noms génériques. Nommez vos calques de façon descriptive ou préfixez-les [deco] pour les images décoratives.

7. Hiérarchie de titres incohérente (SC 1.3.1)

La structure H1 > H2 > H3 doit être logique et sans saut. La hiérarchie des titres est le principal outil de navigation des utilisateurs de lecteurs d’écran.

Comment vérifier dans Figma : Appliquez des styles de texte nommés Heading/H1, Heading/H2, etc. A11y Audit analyse l’ordre d’apparition de ces styles dans la frame et signale les incohérences.

8. Liens identiques avec destinations différentes (SC 2.4.6)

Si deux liens ont le même libellé mais pointent vers des destinations différentes, c’est une violation. Inversement, si le même contenu est accessible depuis deux endroits, les deux liens doivent avoir le même libellé.

Comment vérifier dans Figma : Revue manuelle. Parcourez les liens de votre maquette et vérifiez la cohérence des libellés.

9. Formulaires sans labels associés (SC 1.3.1 et 4.1.2)

Chaque champ de formulaire doit avoir un label visible et explicite. Les placeholders ne remplacent pas les labels (ils disparaissent à la saisie).

Comment vérifier dans Figma : Vérifiez que chaque champ de formulaire de votre maquette a un label positionné au-dessus ou à gauche du champ, visible en tout temps.

10. Contenu qui se réorganise à 400% de zoom (SC 1.4.10)

Le contenu doit être accessible sans scroll horizontal jusqu’à un zoom de 400% (sur une fenêtre de 1280 px de large, cela correspond à 320 px CSS).

Comment vérifier dans Figma : Créez un frame de 320 px de large et adaptez-y votre mise en page. Si le contenu ne tient pas sans scroll horizontal à 320 px, il y a un problème de responsive design à anticiper.

Tableau récapitulatif

Critère WCAG	Comment vérifier dans Figma	Outil
1.4.3 Contraste texte	Audit automatique	A11y Audit
1.4.11 Contraste UI	Audit automatique	A11y Audit
2.5.8 Target size	Audit automatique	A11y Audit
1.1.1 Texte alternatif	Audit + nommage calques	A11y Audit
1.3.1 Hiérarchie titres	Audit + styles de texte	A11y Audit
1.4.1 Couleur seule	Simulateur daltonisme	Figma natif
2.4.11 Focus visible	Revue manuelle des composants	Manuel
2.4.6 Libellés liens	Revue manuelle	Manuel
1.3.1 Labels formulaires	Revue manuelle	Manuel
1.4.10 Reflow 400%	Frame 320px	Figma natif

Intégrer l’accessibilité dans votre workflow design

Voici les étapes pratiques pour intégrer la conformité WCAG dans votre processus de design :

Dès la conception de la charte graphique : Vérifiez que votre palette de couleurs respecte les ratios de contraste. Il est bien plus difficile de corriger les couleurs une fois la charte validée par le client.

À chaque itération de maquette : Lancez un audit A11y Audit à chaque livraison de sprint. Intégrez le score de conformité dans votre compte-rendu de livraison.

Avant la livraison finale au client : Générez le rapport PDF complet. Transmettez-le à l’équipe de développement avec les violations et les recommandations de correction.

Après le développement : Recommandez à votre client un audit de l’application finale avec des outils de test sur l’application (axe DevTools, WAVE, lecteurs d’écran).

Conclusion

L’EAA n’est pas qu’une contrainte réglementaire : les sites accessibles ont en moyenne une meilleure expérience utilisateur pour tous, un meilleur référencement naturel (Google valorise la structure sémantique et les textes alternatifs) et un taux de rebond réduit sur mobile.

Commencez dès maintenant en installant A11y Audit — WCAG 2.2 et en auditant votre prochaine maquette Figma.

Installer le plugin → · Voir les tarifs →