Les WCAG 2.1 AA exigent de respecter tous les critères de succès de niveau A et de niveau AA, soit 50 points de contrôle organisés autour de quatre principes : perceptible, utilisable, compréhensible et robuste. Cette checklist parcourt les domaines pratiques qui comptent le plus pour un site d’entreprise type, regroupés selon ces quatre principes, afin que vous puissiez vérifier votre propre site méthodiquement plutôt que de deviner ce que recouvre réellement la « conformité AA ».

Deux points à connaître avant de parcourir cette liste. D’abord, il s’agit d’un tour d’horizon pratique des domaines les plus importants pour un site d’entreprise type, pas d’une reformulation mot pour mot des 50 critères de succès ; la documentation officielle du W3C reste la source faisant autorité si vous avez besoin du texte juridique exact. Ensuite, « AA » est un niveau, pas une norme distincte : le niveau AA inclut tout ce qu’exige le niveau A, plus les critères supplémentaires de niveau AA, si bien qu’un site revendiquant une conformité AA doit satisfaire les deux paliers ensemble, pas les critères AA isolément.

Perceptible : les utilisateurs peuvent-ils percevoir le contenu

Contraste des couleurs. Le texte a besoin d’un ratio de contraste d’au moins 4,5:1 par rapport à son arrière-plan (3:1 pour le texte de grande taille). C’est le point à vérifier en premier : le rapport WebAIM Million 2026 a constaté que 83,9 % des pages d’accueil présentaient un texte à faible contraste, ce qui en fait l’échec le plus courant sur l’ensemble des données. Un texte gris clair sur fond blanc, un choix de design encore courant dans beaucoup de modèles de site modernes, est un coupable fréquent qui vaut la peine d’être vérifié spécifiquement.

Texte alternatif pour les images. Chaque image porteuse de sens a besoin d’une alternative textuelle décrivant son objectif ou son contenu ; les images purement décoratives doivent avoir des attributs alt vides pour que les lecteurs d’écran les ignorent plutôt que d’annoncer quelque chose de dénué de sens. Les photos produits, les infographies et les icônes porteuses de sens (comme une coche indiquant une réussite) sont les catégories les plus souvent oubliées.

Sous-titres et transcriptions. Les vidéos préenregistrées ont besoin de sous-titres, et le contenu audio seul a besoin d’une transcription. Cela s’applique à tout contenu vidéo intégré, pas seulement à celui que vous avez produit vous-même.

Texte redimensionnable. Le texte doit pouvoir être agrandi jusqu’à 200 % sans perte de contenu ni de fonctionnalité, et le contenu ne doit pas dépendre d’une mise en page à pixels fixes qui se casse lors d’un zoom.

Ne pas s’appuyer uniquement sur la couleur. Toute information transmise par la couleur (une bordure rouge indiquant une erreur de formulaire, par exemple) a besoin d’un second indicateur, comme une icône ou une étiquette textuelle, pour les utilisateurs incapables de percevoir la différence de couleur.

Utilisable : les utilisateurs peuvent-ils naviguer et interagir avec tout

Accès complet au clavier. Chaque élément interactif, liens, boutons, champs de formulaire, widgets personnalisés comme des menus déroulants ou des fenêtres modales, doit être utilisable uniquement au clavier, sans piège clavier empêchant un utilisateur de ressortir par tabulation.

Indicateur de focus visible. Lorsqu’un utilisateur atteint un élément par tabulation, un indicateur visible doit montrer où se trouve actuellement le focus. C’est un domaine que les WCAG 2.2 ont ensuite élargi davantage, mais c’est déjà une exigence de niveau AA sous les WCAG 2.1.

Pas de changements de contenu inattendus. Les éléments ne doivent pas déclencher automatiquement un changement de contexte majeur (comme le chargement d’une nouvelle page) simplement en recevant le focus, et le contenu ne doit pas se déplacer de façon imprévisible pendant l’interaction.

Texte de lien et de titre descriptif. Le texte des liens doit avoir du sens hors contexte (évitez les liens génériques « cliquez ici »), et les pages ont besoin d’une structure de titres logique pour que les utilisateurs de lecteur d’écran puissent naviguer par niveau de titre.

Plusieurs moyens de trouver le contenu. Un site a en général besoin de plus d’un moyen de localiser une page donnée, comme une fonction de recherche associée à un menu de navigation et à un plan du site, plutôt que d’exiger que les utilisateurs connaissent un chemin exact.

Compréhensible : le contenu et le comportement sont-ils prévisibles

Langage et instructions clairs. Les champs de formulaire ont besoin d’étiquettes claires, et les instructions doivent être compréhensibles, en particulier concernant les champs obligatoires et les formats de saisie attendus.

Navigation cohérente. Les menus de navigation et les composants répétés doivent apparaître dans le même ordre relatif d’une page à l’autre, afin que les utilisateurs se construisent un modèle mental exact du site.

Identification des erreurs et suggestions. Lorsque l’envoi d’un formulaire échoue, l’erreur précise doit être identifiée par un texte (pas uniquement par la couleur) et, si possible, une suggestion de correction doit être proposée.

Comportement prévisible lors de la saisie. Modifier la valeur ou le réglage d’un champ de formulaire ne doit pas déclencher automatiquement un changement de contexte inattendu, comme l’envoi du formulaire ou un changement de page, sans une action explicite de l’utilisateur.

Robuste : le contenu fonctionne-t-il avec les technologies d’assistance

Balisage valide et bien structuré. Bien que l’ancien critère 4.1.1 sur l’analyse syntaxique ait été retiré dans les WCAG 2.2, disposer d’un HTML propre et conforme aux standards compte toujours en pratique pour une prise en charge fiable par les technologies d’assistance.

Nom, rôle et valeur corrects pour les composants personnalisés. Tout composant interactif personnalisé (un menu déroulant, un panneau d’onglets ou une fenêtre modale construits entièrement sur mesure plutôt qu’avec des éléments HTML natifs) a besoin des rôles, états et propriétés ARIA corrects afin que les technologies d’assistance puissent l’identifier et interagir correctement avec lui.

Messages de statut. Les mises à jour de statut dynamiques, comme une confirmation « article ajouté au panier » ou un résultat de validation de formulaire, doivent être annoncées aux utilisateurs de lecteur d’écran sans exiger qu’ils déplacent manuellement leur focus.

Un ordre simple pour la parcourir

Essayer de corriger les 50 critères d’un coup tend à bloquer un projet avant même qu’il ne commence, une priorisation approximative aide donc. Commencez par les problèmes à la fois à fort impact et faciles à vérifier : le contraste des couleurs et le texte alternatif manquant, car les deux sont fréquents (les échecs de contraste à eux seuls apparaissaient sur 83,9 % des pages d’accueil dans l’étude WebAIM Million 2026) et simples à vérifier avec un scanner. Passez ensuite à l’accès clavier sur vos parcours de conversion essentiels, car un utilisateur incapable de finaliser un paiement ou une inscription au clavier seul est totalement bloqué, pas simplement gêné. Traitez ensuite l’étiquetage des formulaires et les messages d’erreur, un domaine où beaucoup de composants personnalisés sont discrètement défaillants, même sur des sites par ailleurs raisonnablement accessibles. Réservez les critères qui demandent le plus de jugement, comme le fait de savoir si une structure de titres est réellement logique ou si un message de statut est correctement annoncé à un lecteur d’écran, pour un passage de test manuel dédié une fois les problèmes plus mécaniques réglés.

Comment parcourir concrètement cette checklist

Les outils de scan automatisés, y compris ceux construits sur le moteur axe-core de Deque largement utilisé, constituent un premier passage réellement utile et détecteront rapidement une part réelle de ces problèmes, en particulier ceux liés au contraste et au texte alternatif manquant. Mais les outils automatisés ne peuvent pas tout évaluer sur cette liste : le fait qu’une structure de titres soit logique, qu’une étiquette ARIA soit réellement exacte, ou qu’un utilisateur de lecteur d’écran puisse finaliser votre parcours de paiement dans un ordre sensé, tout cela exige un testeur humain, idéalement utilisant une véritable technologie d’assistance sur vos parcours utilisateurs clés. Certains éditeurs, comme Wawsome, associent des vérifications automatisées basées sur un widget à un vérificateur revu par des humains précisément pour couvrir cet écart, tandis que d’autres comme UserWay proposent un scan automatisé avec un audit manuel professionnel en option pour un passage plus approfondi.

Si vous hésitez à intégrer cette checklist à un processus interne ou à faire appel à une aide extérieure, notre guide sur le choix entre un widget et un audit manuel détaille comment prendre cette décision en fonction des ressources de votre équipe.