Liste de vérification de l'accessibilité web : WCAG 2.2 pour les designers qui travaillent vraiment
Une liste de vérification d'accessibilité WCAG 2.2 organisée selon l'endroit où le travail se fait : Figma, navigateur, après le lancement. Plus une correspondance erreurs de designer/critères.
La plupart des listes de vérification de l'accessibilité web sont inutiles pour les designers. Elles sont organisées par numéro de critère de succès WCAG, ce qui est la façon dont un avocat lit les spécifications et dont personne ne construit des logiciels.
Les designers n'ouvrent pas Figma en pensant au critère 1.4.3. Ils ouvrent Figma et choisissent une couleur de texte. La liste utile rejoint le designer là où la décision se prend, ce qui signifie trois listes distinctes : une pour le fichier de design, une pour le navigateur, une pour après le lancement. Organisez-la autrement et elle sera ignorée.
Ce que WCAG 2.2 exige réellement
WCAG 2.2 est la norme mondiale actuelle en 2026, et elle ajoute neuf nouveaux critères de succès par rapport à WCAG 2.1, principalement axés sur le mobile, les cibles tactiles, la charge cognitive et l'authentification.
Les neuf nouveaux critères qui comptent pour les designers forment une courte liste. L'apparence du focus devient plus stricte (2.4.11, 2.4.13). Les gestes de glisser nécessitent désormais une alternative sans glisser (2.5.7). Les cibles tactiles ont une taille minimale de 24 par 24 pixels CSS, sauf si la cible dispose d'un espacement suffisant autour d'elle (2.5.8). Un emplacement cohérent des aides sur les pages est requis (3.2.6). Les formulaires ne peuvent pas demander les mêmes informations deux fois sans nécessité (3.3.7). L'authentification ne peut pas reposer sur un test cognitif comme mémoriser un mot de passe sans alternative (3.3.8, 3.3.9).
AA est le niveau requis par la plupart des lois sur l'accessibilité dans le monde, notamment l'European Accessibility Act de l'UE, la Section 508 aux États-Unis et les Public Sector Bodies Accessibility Regulations au Royaume-Uni. AAA est plus strict et réservé principalement aux secteurs gouvernemental, médical et éducatif.
Une liste organisée par numéros de section WCAG est une spécification. Une liste organisée selon l'endroit où le travail se fait est un outil.
Le seul format de liste qui fonctionne
Il y a trois endroits où l'accessibilité se décide. Le fichier de design. L'interface construite dans un navigateur. Le site en production après le lancement.
Environ 70 % des échecs d'accessibilité sont des décisions prises dans Figma, 20 % sont prises lors de l'implémentation, et 10 % s'infiltrent après le lancement via des modifications de contenu, des intégrations tierces ou du contenu généré par les utilisateurs. Toute liste qui ne correspond pas à ces trois phases oblige le designer à traduire du langage de spécification en langage de workflow, et c'est dans cette traduction que les éléments sont oubliés.
Le reste de cet article est constitué des trois listes, dans l'ordre. Exécutez-les dans l'ordre. Tout ce qui échoue à la vérification de la phase de design ne devrait jamais atteindre la phase de construction. Tout ce qui échoue à la phase de construction ne devrait jamais être mis en ligne.
Liste de la phase de design (ce que vous vérifiez dans Figma)
Environ 70 % des échecs d'accessibilité sont des décisions prises dans le fichier de design, ce qui signifie qu'ils sont aussi les moins coûteux à corriger à ce stade.
| Vérification | Critère WCAG 2.2 | Comment vérifier dans Figma |
|---|---|---|
| Le texte courant atteint un contraste de 4,5:1 avec son arrière-plan | 1.4.3 Contrast (Minimum) | Stark, Able, ou le vérificateur de contraste intégré de Figma |
| Le grand texte (18 pt+ ou 14 pt+ gras) atteint 3:1 | 1.4.3 | Les mêmes outils |
| Les éléments UI non textuels (boutons, bordures, icônes, anneaux de focus) atteignent 3:1 | 1.4.11 Non-text Contrast | Échantillonner manuellement les paires de couleurs sur le canvas |
| Les cibles tactiles font au moins 24 par 24 px CSS (48 par 48 recommandé) | 2.5.8 Target Size (Minimum) | Mesurer directement les dimensions du cadre |
| L'information n'est pas transmise uniquement par la couleur | 1.4.1 Use of Color | Passer le cadre en niveaux de gris (plugin Figma ou filtre de capture d'écran) |
| Chaque cadre d'image dispose d'un texte alternatif dans les métadonnées de calque | 1.1.1 Non-text Content | Panneau d'accessibilité de Figma ou mode dev |
| Les titres sont utilisés dans un ordre logique (H1, H2, H3, pas H1, H3, H2) | 1.3.1 Info and Relationships | Lire l'arborescence des titres de haut en bas |
| L'état de focus est conçu pour chaque élément interactif | 2.4.7 Focus Visible, 2.4.11 Focus Not Obscured | Chaque composant interactif a une variante de focus |
| Le texte des liens a du sens hors contexte | 2.4.4 Link Purpose | Pas de libellés « cliquez ici » ni « en savoir plus » |
| Les étiquettes de formulaire sont visibles, pas seulement sous forme de placeholder | 3.3.2 Labels or Instructions | Chaque champ a une étiquette persistante en dehors de l'input |
Le fichier de design est aussi l'endroit où vous repérez les nouveaux critères mobiles de WCAG 2.2. Les cibles tactiles qui échouent au critère 2.5.8 échouent presque toujours parce que le designer pensait en pixels desktop et que la cible est une icône de 16 pixels sans padding.
Pour une analyse plus approfondie du contraste, consultez les règles de contraste et APCA. Le travail sur les couleurs en phase de design est là où la plupart des sites échouent à l'audit avant qu'une seule ligne de code soit écrite.
Liste de la phase de construction (ce que vous vérifiez dans le navigateur)
Le navigateur est l'endroit où les décisions d'accessibilité sont prouvées ou exposées, car c'est le premier endroit où les technologies d'assistance réelles touchent votre travail.
| Vérification | Critère WCAG 2.2 | Comment vérifier dans le navigateur |
|---|---|---|
| Chaque page fonctionne au clavier uniquement (tab, shift-tab, entrée, espace, touches directionnelles) | 2.1.1 Keyboard | Débrancher la souris et naviguer dans la page |
| L'ordre du focus suit l'ordre visuel (gauche à droite, haut en bas en LTR) | 2.4.3 Focus Order | Naviguer avec Tab et observer l'anneau de focus |
| Le focus n'est jamais masqué par des en-têtes fixes, des bannières de cookies ou des modales | 2.4.11 Focus Not Obscured (Minimum) | Faire défiler tout en naviguant avec Tab pour confirmer la visibilité |
| Les interactions de glisser ont une alternative par clic ou tap | 2.5.7 Dragging Movements | Vérifier les curseurs, les listes triables, les carrousels |
| Le lien « aller au contenu » apparaît au premier Tab | 2.4.1 Bypass Blocks | Appuyer une fois sur Tab au chargement de la page |
| Les landmarks HTML sont utilisés (header, nav, main, footer, aside) | 1.3.1, 4.1.2 | Inspecter le plan du DOM |
| Les erreurs de formulaire sont annoncées, pas seulement codées par couleur | 3.3.1, 3.3.3, 4.1.3 | Soumettre un formulaire incorrect avec un lecteur d'écran |
| Le lecteur d'écran annonce correctement les titres, listes et boutons | 4.1.2 Name, Role, Value | NVDA sous Windows, VoiceOver sur Mac, TalkBack sur Android |
| Les attributs autocomplete sont définis sur les champs de données personnelles | 1.3.5 Identify Input Purpose | Inspecter autocomplete sur les champs nom, email, adresse |
| Les médias ont des sous-titres, des transcriptions ou des descriptions audio | 1.2.1 à 1.2.5 | Lire chaque vidéo, vérifier les pistes |
Les outils automatisés détectent environ 30 % de ces problèmes. Le reste nécessite un humain qui appuie sur Tab et écoute un lecteur d'écran. Les deux comptent, et aucun ne remplace l'autre.
La meilleure pile d'outils pour la phase navigateur en 2026 est petite : axe DevTools pour le scan automatisé, Lighthouse pour les audits au niveau de la page, et un vrai lecteur d'écran pour la passe manuelle. Trois outils, dix minutes par page, capturent presque tout ce qu'un vrai audit signalerait.
Liste post-lancement (ce que vous vérifiez en production)
L'accessibilité ne s'arrête pas au lancement, car le contenu, les intégrations tierces et le contenu généré par les utilisateurs arrivent tous après que le designer a validé.
| Vérification | Critère WCAG 2.2 | Comment vérifier en production |
|---|---|---|
| Les images créées dans le CMS ont un texte alternatif rendu obligatoire au niveau de l'éditeur | 1.1.1 | Tester le CMS : un auteur peut-il publier sans texte alternatif ? |
| Les widgets tiers intégrés (chat, cartes, formulaires) sont accessibles | Variable | Lancer axe sur les pages avec des intégrations |
| Les téléchargements PDF et documents sont balisés et lisibles | 1.1.1, 1.3.1, 2.4.6 | Ouvrir dans le vérificateur d'accessibilité d'Acrobat |
| Les liens d'aide, de support et de contact sont au même endroit sur chaque page | 3.2.6 Consistent Help (WCAG 2.2 nouveau) | Audit visuel sur les templates |
| Les formulaires ne demandent pas d'informations redondantes dans un flux | 3.3.7 Redundant Entry (WCAG 2.2 nouveau) | Parcourir les formulaires en plusieurs étapes |
| L'authentification dispose d'une alternative accessible (passkeys, liens email, SSO) | 3.3.8, 3.3.9 Accessible Authentication (WCAG 2.2 nouveau) | Essayer l'inscription et la connexion avec un gestionnaire de mots de passe bloqué |
| Le contenu dynamique (modales, toasts, régions live) est annoncé | 4.1.3 Status Messages | Déclencher chacun avec un lecteur d'écran ouvert |
| La page continue de respecter les règles de contraste et de taille de cible après un zoom utilisateur à 200 % | 1.4.4 Resize Text, 1.4.10 Reflow | Zoomer le navigateur à 200 % et vérifier |
| Pas de médias en lecture automatique, ou les médias ont un contrôle de pause | 1.4.2 Audio Control, 2.2.2 Pause, Stop, Hide | Charger la page à froid |
| La bannière de cookies ne piège pas le focus clavier | 2.1.2 No Keyboard Trap | Naviguer dans la bannière avec Tab, puis en ressortir |
La liste post-lancement est là où la plupart des équipes échouent. Le design a été livré de manière accessible. Les auteurs CMS le remplissent de PDFs non balisés, de vidéos en lecture automatique et d'un widget de chat avec un ratio de contraste de 2:1 sur son bouton d'ouverture. L'accessibilité est une propriété du système, pas une étape de lancement.
Erreurs courantes des designers associées aux critères WCAG
Chaque constat d'audit d'accessibilité remonte à un critère de succès WCAG spécifique, et la plupart des designers font les mêmes dix erreurs contre les mêmes dix critères.
| Erreur du designer | Ce que c'est vraiment | Critère WCAG 2.2 violé |
|---|---|---|
| Le texte placeholder comme seule étiquette | Les utilisateurs perdent l'étiquette au moment où ils commencent à taper | 3.3.2 Labels or Instructions |
| Boutons avec icône seule sans aria-label ni infobulle | Les lecteurs d'écran annoncent « bouton » sans préciser son objectif | 4.1.2 Name, Role, Value |
| Messages d'erreur affichés uniquement avec une bordure rouge ou du texte rouge | Les utilisateurs daltoniens ne voient aucune erreur | 1.4.1 Use of Color, 3.3.1 Error Identification |
| Anneau de focus supprimé pour des raisons esthétiques | Les utilisateurs clavier ne peuvent pas voir où ils se trouvent | 2.4.7 Focus Visible |
| Cibles tactiles inférieures à 24 par 24 px sans espacement | Les utilisateurs mobiles ratent constamment leur cible | 2.5.8 Target Size (Minimum) |
| Faible contraste sur l'UI « subtile » (texte placeholder, états désactivés, texte d'aide) | Les lecteurs en plein soleil ou avec une perte de vision ne peuvent pas le lire | 1.4.3 Contrast (Minimum), 1.4.11 Non-text Contrast |
| Modale qui piège le focus mais sans fermeture via ESC | Les utilisateurs clavier sont bloqués dans la modale | 2.1.2 No Keyboard Trap |
| Carrousels avec navigation uniquement par glisser | Les utilisateurs ayant des limitations motrices ne peuvent pas avancer | 2.5.7 Dragging Movements |
| En-tête fixe qui masque l'élément ciblé lors de la navigation Tab | Les utilisateurs voient la page défiler mais perdent la trace de leur position | 2.4.11 Focus Not Obscured |
| Connexion avec mot de passe uniquement, sans SSO ni lien email | Échec lié à la charge cognitive | 3.3.8 Accessible Authentication |
Ces dix mêmes erreurs constituent la majorité de chaque rapport d'audit. Corrigez-les et vous êtes à 80 % du chemin vers WCAG 2.2 AA avant qu'un consultant n'ouvre une feuille de calcul.
Les bases de l'accessibilité se connectent aussi au reste d'une bonne hiérarchie visuelle. Le contraste, la taille des cibles et les états de focus sont des décisions de hiérarchie. Un design qui maîtrise la hiérarchie maîtrise par défaut la majeure partie de la liste d'accessibilité, ce qui explique pourquoi le chevauchement entre une bonne théorie des couleurs et le design accessible est presque total.
Comment exécuter la liste sans y passer une semaine
La liste n'est utile que si l'exécuter prend des minutes, pas des jours, ce qui signifie que les outils doivent faire la majeure partie du travail.
La cadence de travail est de trois passages, un par phase, chacun effectué au moment où le travail atteint cette phase. Pas les trois à la fin. Pas un seul à la fin. Trois passages séparés, chacun économique, chacun appliqué par des outils là où c'est possible.
- Passage design : 10 minutes par écran. Stark ou le vérificateur de contraste de Figma sur chaque paire de texte, passage en niveaux de gris du cadre pour tester les informations transmises uniquement par la couleur, mesure de chaque cible tactile. À faire avant la passation, pas pendant la revue.
- Passage construction : 10 minutes par template. Scan axe DevTools, test de navigation uniquement au clavier, un passage lecteur d'écran sur les pages les plus visitées. Intégrer axe-core dans la CI pour que le nouveau code ne puisse pas fusionner avec des régressions.
- Passage lancement : mensuel, pas par release. Crawl axe ou pa11y complet du site en production, audit PDF sur toute bibliothèque de documents, parcours manuel des formulaires et flux d'authentification.
C'est une demi-journée de travail par mois et par produit, et peut-être 15 minutes par passation de design. Plus que ça et l'équipe arrêtera de l'exécuter. Moins que ça et les audits reviennent non corrigés.
FAQ
WCAG 2.2 est-il légalement obligatoire ?
Oui, dans la plupart des grands marchés. L'European Accessibility Act est entré en vigueur en juin 2025 et référence WCAG 2.1 au minimum, avec 2.2 comme norme de travail actuelle. La Section 508 aux États-Unis référence WCAG 2.0, mais les contrats publics exigent de plus en plus la version 2.2. Le Canada, le Royaume-Uni, l'Australie et le Japon ont tous des exigences similaires liées à WCAG 2.1 ou 2.2. Si vous livrez dans l'un de ces marchés, 2.2 AA est la cible sûre.
Quels sont les nouveaux critères WCAG 2.2 que je dois vraiment connaître ?
Quatre comptent le plus pour les designers. 2.5.7 Dragging Movements exige une alternative sans glisser pour les interactions de glisser. 2.5.8 Target Size (Minimum) exige des cibles tactiles d'au moins 24 par 24 pixels CSS avec un espacement suffisant. 2.4.11 Focus Not Obscured exige que l'élément ciblé reste visible lors du défilement et des superpositions fixes. 3.3.8 Accessible Authentication interdit les tests cognitifs comme mémoriser un mot de passe sans alternative (SSO, passkey ou lien email).
Ai-je besoin d'une liste séparée pour le mobile ?
Non. WCAG 2.2 est explicitement rédigé pour couvrir le mobile et le tactile, c'est pourquoi tant de ses nouveaux critères (taille de cible, glisser, focus) sont adaptés au mobile. La même liste en trois phases fonctionne pour le web mobile et le design responsive. Les applications natives ont des directives supplémentaires spécifiques à chaque plateforme (HIG d'Apple et Android Accessibility), mais les règles WCAG s'appliquent quand même.
Quelle est la taille minimale de cible tactile dans WCAG 2.2 ?
24 par 24 pixels CSS est le minimum selon 2.5.8 Target Size (Minimum), mais il y a des exceptions si les cibles ont suffisamment d'espacement autour d'elles ou sont en ligne avec du texte. La cible pratique que la plupart des designers devraient viser est 48 par 48 pixels CSS, ce qui correspond aux recommandations des plateformes d'Apple et Google et évite les cas limites dans la spécification WCAG.
Livrez la liste, pas les approximations
L'accessibilité n'est pas une tâche de conformité. C'est une propriété de design, construite à trois moments, appliquée par des outils, vérifiée par des humains.
Les équipes qui livrent des sites accessibles sans douleur ne sont pas celles qui ont les meilleurs auditeurs. Ce sont celles qui ont déplacé les vérifications dans la phase de design, la phase de construction et la phase de lancement, et qui ont refusé de laisser le travail avancer au-delà de l'une d'elles avec des échecs connus.
Exécutez les trois listes. Repérez les dix erreurs courantes avant qu'elles ne s'accumulent. Automatisez les scans de la phase navigateur dans la CI. Auditez la dérive post-lancement mensuellement. WCAG 2.2 AA cesse d'être une ligne d'arrivée et devient une propriété de la façon dont l'équipe travaille.
Choisissez une surface produit sur votre site aujourd'hui. Exécutez la liste de la phase de design sur son fichier Figma. Comptez les corrections. Ce nombre est le coût de ne pas avoir fait cela plus tôt.
Livrez la liste, pas les approximations.
Need a site that passes WCAG 2.2 without a three-month remediation cycle? Brainy ships accessible design from the first Figma frame.
Get Started
