La checklist accessibilité web (WCAG 2.2 / RGAA)

Cette checklist d'accessibilité web s'adresse aux designers, pas seulement aux auditeurs : les décisions qui font ou défont l'accessibilité se prennent dans Figma bien avant qu'un développeur touche au code. Elle s'appuie sur les Web Content Accessibility Guidelines (WCAG) 2.2 du W3C (initiative WAI) et, en France, sur le RGAA qui en est la déclinaison. Utilisez-la comme un point de contrôle en revue de design, pas comme un correctif de dernière minute.

Couleur et contraste

Le contraste est l'échec le plus fréquent et le plus facile à corriger. WCAG 2.2 exige un ratio d'au moins 4,5:1 pour le texte normal et 3:1 pour le grand texte (environ 24px, ou 19px en gras). Les éléments non textuels comme les icônes, bordures de champ et indicateurs de focus exigent au moins 3:1 sur leur fond.

• Vérifiez le texte sur son fond réel, y compris sur images et dégradés.
• Ne reposez jamais sur la couleur seule ; associez texte, icônes ou motifs.
• Testez votre palette en thème clair et sombre.

Focus visible et accès clavier

Chaque élément interactif doit être atteignable et activable au clavier, avec un indicateur de focus nettement visible. WCAG 2.2 a renforcé ce point : le nouveau critère Focus non masqué impose qu'un élément focalisé ne soit pas entièrement caché derrière des en-têtes collants, bannières cookies ou widgets de chat.

• Concevez un état de focus délibéré — ne laissez pas le style par défaut être supprimé par accident.
• Assurez un ordre de tabulation logique, conforme à l'ordre visuel.
• Tenez compte des UI collantes/superposées pour que les contrôles restent visibles.

Taille des cibles et pointeur

Le nouveau critère WCAG 2.2 Taille de cible (minimum) demande des cibles interactives d'au moins 24×24 pixels CSS, ou un espacement suffisant autour des plus petites. Cela protège les personnes à mobilité réduite et tout utilisateur sur écran tactile.

• Donnez aux boutons, icônes et liens assez de marge et d'espacement.
• Évitez les minuscules boutons de fermeture et les rangées d'icônes serrées.

Formulaires et erreurs

Les formulaires sont l'endroit où l'accessibilité affecte le plus directement la conversion. Chaque champ a besoin d'un label persistant et associé par programme — le texte d'invite (placeholder) n'est pas un label. WCAG 2.2 a aussi ajouté Authentification accessible et Saisie redondante, qui découragent de faire mémoriser ou re-saisir une information déjà fournie.

• Utilisez des labels visibles, pas des champs à placeholder seul.
• Décrivez les erreurs en texte, identifiez le champ et proposez une correction.
• Ne désactivez pas le copier-coller dans les champs mot de passe ou code.
• Évitez les CAPTCHA cognitifs comme seul moyen d'authentification.

Mouvement et animation

L'animation peut déclencher des troubles vestibulaires. Respectez la requête média prefers-reduced-motion et évitez parallaxe, carrousels en lecture automatique et mouvements amples inattendus. Tout contenu qui bouge, clignote ou défile automatiquement plus de cinq secondes doit offrir une commande de pause.

Images et texte alternatif

Chaque image porteuse de sens a besoin d'un texte alternatif décrivant sa fonction, pas son apparence. Les images décoratives doivent avoir un attribut alt vide pour que les lecteurs d'écran les ignorent. Pour les graphiques complexes, fournissez un résumé textuel ou un tableau de données à proximité.

Pourquoi c'est désormais un socle légal

L'accessibilité est de plus en plus une obligation légale, pas un agrément. L'European Accessibility Act fixe des obligations contraignantes pour de nombreux produits et services numériques dans l'UE, et le RGAA encadre déjà le secteur public en France. Atteindre le niveau AA de WCAG 2.2 est la voie pratique pour y répondre et, surtout, pour servir chaque utilisateur. Intégrez la checklist aux revues de design pour attraper les problèmes tant qu'ils sont peu coûteux à corriger.