WCAG 2.2 vs WCAG 2.1 : ce qui change et ce que vous devez mettre à jour

Plus de 96 % des pages d’accueil ne respectent toujours pas les exigences de base des WCAG, selon l’analyse d’accessibilité 2024 de WebAIM — et cela par rapport à une norme qui avait déjà cinq ans. Le 5 octobre 2023, le W3C a publié WCAG 2.2 en tant que norme web officielle, en élevant le niveau avec neuf nouveaux critères de succès et en retirant un critère devenu obsolète. Si vous gérez un site web, concevez des produits numériques ou supervisez la conformité, cette mise à jour n’est pas quelque chose que vous pouvez repousser indéfiniment. Les réglementations dans l’UE, au Royaume-Uni et, de plus en plus, dans les États américains, évoluent déjà pour faire référence à WCAG 2.2 comme leur référence.

Un bref historique : de WCAG 2.1 à WCAG 2.2

Les Web Content Accessibility Guidelines ont évolué régulièrement depuis le lancement de WCAG 2.0 en décembre 2008. WCAG 2.1 est arrivé en juin 2018, ajoutant 17 nouveaux critères de succès avec un accent particulier sur les utilisateurs mobiles et les personnes ayant une basse vision ou des troubles cognitifs. Pendant cinq ans, il a servi de référence de conformité de facto pour des lois comme l’ADA, la Section 508 et la directive européenne sur l’accessibilité du web.

WCAG 2.2 reprend exactement là où 2.1 s’est arrêté. Le W3C l’a lancé avec l’objectif explicite de continuer à améliorer les recommandations en matière d’accessibilité pour trois grands groupes : les utilisateurs ayant des troubles cognitifs ou d’apprentissage, les utilisateurs ayant une basse vision et les utilisateurs en situation de handicap sur appareils mobiles. Cette filiation est importante car elle signifie que la mise à jour est évolutive, non révolutionnaire — mais elle est tout de même suffisamment significative pour nécessiter une action de votre part.

L’un des points les plus importants à comprendre structurellement est que WCAG 2.2 est entièrement rétrocompatible avec WCAG 2.1. Se conformer à WCAG 2.2 signifie automatiquement que vous vous conformez également à WCAG 2.1 et WCAG 2.0. Si votre organisation est actuellement conforme à WCAG 2.1 AA, vous n’avez qu’à traiter les nouveaux critères introduits dans 2.2 — vous ne repartez pas de zéro. Le W3C conseille également que, bien que WCAG 2.0 et 2.1 restent des recommandations valides, les organisations devraient utiliser WCAG 2.2 pour maximiser l’applicabilité future de leur travail en accessibilité.

WCAG 2.2 devrait également être largement la dernière version « point » de la famille WCAG 2.x. La prochaine version majeure, WCAG 3.0, est une tout autre bête — une refonte complète de la manière dont les directives d’accessibilité sont structurées. Cela fait de WCAG 2.2 le point final définitif d’une lignée qui remonte à 2008, et celui qu’il vous faut maîtriser dès maintenant.

Les chiffres : ce qui a réellement changé

Précisons la portée du changement. WCAG 2.1 contenait 78 critères de succès répartis sur trois niveaux de conformité (A, AA et AAA). WCAG 2.2 ajoute neuf nouveaux critères de succès tout en en supprimant un — le critère de succès 4.1.1 Parsing — laissant un total de 86 critères actifs. Sur ces neuf ajouts, deux sont au niveau A, quatre au niveau AA et trois au niveau AAA.

Pour la grande majorité des organisations visant la conformité de niveau AA — le niveau mentionné dans la plupart des lois et réglementations — l’impact pratique est de six nouveaux critères à mettre en œuvre. Les trois ajouts de niveau AAA sont considérés comme des bonnes pratiques et sont souvent recommandés dans les contextes gouvernementaux et de santé, mais ils ne constituent pas une exigence légale stricte dans la plupart des juridictions aujourd’hui.

Les nouveaux critères traitent principalement de quatre domaines problématiques que les audits d’accessibilité en conditions réelles avaient à plusieurs reprises signalés comme insuffisamment couverts par la norme existante : la visibilité du focus clavier, les interactions tactiles et au pointeur, l’accessibilité cognitive et les obstacles à l’authentification. Ce ne sont pas des préoccupations théoriques. Ce sont le type de barrières qui empêchent régulièrement les personnes en situation de handicap d’accomplir des tâches quotidiennes comme se connecter, remplir un formulaire ou naviguer sur une page avec un en-tête fixe.

Les neuf nouveaux critères de succès expliqués

Voici une présentation de chaque nouveau critère, de ce qu’il exige et de pourquoi il est important en pratique. Les critères sont présentés par niveau de conformité afin que vous puissiez hiérarchiser votre travail de remédiation.

Niveau A (Minimum — requis pour tous)

• 2.4.11 Focus not obscured (Minimum) : Lorsqu’un composant d’interface utilisateur reçoit le focus clavier, il ne doit pas être entièrement masqué par un contenu créé par l’auteur. Les coupables les plus courants sont les en-têtes fixes, les bannières de cookies flottantes et les widgets de chat en direct qui se superposent à la page. Si un utilisateur qui appuie sur Tab arrive sur un bouton qui est complètement couvert par votre barre de navigation fixe, ce critère est violé. Notez qu’un élément partiellement masqué est acceptable au niveau A — l’élément ne peut simplement pas être caché à 100 %.
• 2.5.7 Dragging movements : Toute fonctionnalité qui nécessite un mouvement de glisser — pensez aux dépôts de fichiers par glisser-déposer, aux éléments de liste triables ou aux contrôles de type curseur — doit également être opérable avec une action de pointeur unique (comme un clic ou un tap) sans glisser. C’est essentiel pour les utilisateurs ayant des limitations motrices qui ne peuvent pas exécuter de manière fiable des gestes de glisser contrôlés. L’exigence s’applique au contenu créé par l’auteur ; les comportements natifs du navigateur sont exemptés.

Niveau AA (Requis pour la conformité standard)

• 2.4.12 Focus not obscured (Enhanced) : Une version plus stricte de 2.4.11. Au niveau AA, aucune partie de l’indicateur de focus ne peut être masquée par un contenu créé par l’auteur lorsqu’un élément reçoit le focus clavier. Cela ferme la faille de la version de niveau A et exige que les éléments focalisés soient entièrement visibles — et pas seulement partiellement.
• 2.5.8 Target size (Minimum) : La zone cliquable ou tappable des éléments interactifs doit être d’au moins 24×24 pixels CSS, avec des exceptions spécifiques pour les liens textuels en ligne, les éléments contrôlés par l’agent utilisateur et les cas où une cible équivalente de 24×24 existe à proximité. Il s’agit d’un changement significatif par rapport à WCAG 2.1, où une taille de cible de 44×44 pixels n’était recommandée qu’au niveau AAA. Désormais, un minimum de base est applicable au niveau AA. Notez que si 24×24 px est le plancher, le critère AAA (2.5.5) recommande toujours 44×44 px, ce qui reste la référence pour un design adapté au tactile.
• 3.2.6 Consistent help : Si un site web fournit des mécanismes d’aide — coordonnées de contact humain, outils d’auto-assistance, chat automatisé ou formulaire de contact — et que ces mécanismes apparaissent sur plusieurs pages, ils doivent apparaître à la même position relative sur ces pages. Les utilisateurs qui ont besoin d’aide, en particulier ceux ayant des troubles cognitifs, doivent toujours pouvoir la trouver au même endroit sans chercher.
• 3.3.7 Redundant entry : Les informations qu’un utilisateur a déjà saisies à une étape précédente du même processus doivent soit être préremplies pour lui, soit disponibles à la sélection, afin qu’il n’ait pas à les retaper. Pensez aux parcours de paiement en plusieurs étapes qui demandent une adresse de facturation puis redemandent une adresse de livraison — il faut proposer aux utilisateurs un moyen de copier ce qu’ils ont déjà saisi. Des exceptions sont autorisées lorsque la ressaisie des informations est essentielle pour la sécurité (comme la confirmation d’un mot de passe) ou lorsque les données saisies précédemment ne sont plus valides.
• 3.3.8 Accessible authentication (Minimum) : Les tests de fonction cognitive — comme résoudre un puzzle, mémoriser un mot de passe ou retranscrire des caractères à partir d’un CAPTCHA image — ne doivent pas être exigés comme seul moyen d’authentification. Une méthode alternative doit être disponible, ou un mécanisme doit assister l’utilisateur (par exemple, autoriser l’utilisation d’un gestionnaire de mots de passe ou permettre le copier-coller dans le champ de mot de passe). Ce critère n’interdit pas les CAPTCHA en soi, mais il exige qu’ils ne soient jamais la seule option pour les utilisateurs qui ne peuvent pas les compléter.

Niveau AAA (Amélioré — recommandé mais non obligatoire pour la plupart)

• 2.4.13 Focus appearance : Lorsque l’indicateur de focus clavier est visible, il doit respecter des exigences minimales spécifiques en matière de taille et de contraste : la zone de focus doit être au moins aussi grande qu’un périmètre de 2 pixels CSS d’épaisseur autour de l’élément, et il doit y avoir un ratio de contraste d’au moins 3:1 entre les états focalisé et non focalisé. Ce critère était initialement prévu pour le niveau AA mais a été déplacé au niveau AAA en raison de sa complexité. Cela signifie que pour une conformité AA uniquement, il n’existe toujours pas de taille minimale normativement définie pour un indicateur de focus — seulement l’obligation qu’un indicateur soit visible.
• 2.5.9 Dragging movements (Enhanced) : Attendez — il n’y a pas de 2.5.9 dans cette version. L’amélioration AAA concernant le glisser est couverte dans 3.3.9 ci-dessous.
• 3.3.9 Accessible authentication (Enhanced) : Une version plus stricte de 3.3.8. Au niveau AAA, les tests de reconnaissance d’objets et de contenu personnel (comme « cliquez sur tous les feux de circulation » ou « sélectionnez des photos de votre compte ») sont également interdits, et pas seulement les exceptions prévues au niveau AA. Il ne reste plus que deux exceptions au lieu de quatre.

Ce qui a été supprimé : 4.1.1 Parsing

WCAG 2.2 supprime un critère de succès en place depuis WCAG 2.0 : 4.1.1 Parsing. Ce critère exigeait à l’origine que le HTML soit bien formé, avec des balises de début et de fin complètes, un bon emboîtement et aucune duplication d’attributs. L’objectif était de garantir que les navigateurs et les technologies d’assistance puissent analyser le balisage de manière fiable et présenter correctement le contenu aux utilisateurs.

La suppression n’est pas controversée — elle reflète un véritable changement dans le paysage technique. Depuis 2008, les navigateurs sont devenus extrêmement performants pour gérer de manière robuste le HTML mal formé, en suivant un algorithme d’auto-correction cohérent et standardisé. Les technologies d’assistance comme les lecteurs d’écran s’appuient désormais sur le Document Object Model (DOM) du navigateur, et non sur le code source HTML brut. Le W3C a conclu que le critère n’apporte plus de bénéfice significatif en matière d’accessibilité dans l’environnement moderne. Les problèmes d’accessibilité qui étaient auparavant couverts par 4.1.1 le sont toujours par des critères plus spécifiques comme 1.3.1 (Info and relationships) et 4.1.2 (Name, role, value).

Les implications pratiques pour votre équipe : si vos outils de test automatisés signalaient des échecs de 4.1.1 Parsing, ce ne sont plus des problèmes WCAG 2.2. Vous pouvez constater une réduction des échecs signalés uniquement en raison de la mise à jour de version, et non parce que quelque chose a été corrigé. Cela dit, écrire un HTML valide et bien structuré reste une très bonne pratique — ce n’est simplement plus une exigence de conformité en soi.

Implications réglementaires et juridiques

Comprendre les nouveaux critères est une chose. Comprendre ce qu’ils signifient pour votre exposition juridique en est une autre. La réponse courte est : WCAG 2.2 est en train de devenir la norme juridique dans de multiples juridictions, et le calendrier avance plus vite que beaucoup d’organisations ne le pensent.

Au Royaume-Uni, les organismes du secteur public sont déjà tenus de respecter WCAG 2.2 niveau AA en vertu des Public Sector Bodies Accessibility Regulations. Dans l’Union européenne, la norme EN 301 549 — la norme technique qui sous-tend l’European Accessibility Act — est en cours d’adoption de WCAG 2.2 comme base. L’EAA elle-même a une date limite d’application en juin 2025 pour la plupart des organisations du secteur privé offrant des produits et services dans l’UE. Plusieurs États américains, dont le Colorado, ont également exprimé leur intention de mettre à jour leurs lois d’accessibilité de l’État de WCAG 2.1 vers WCAG 2.2.

Aux États-Unis, le Title II de l’ADA fait actuellement référence à WCAG 2.1 AA comme norme technique pour les sites web des gouvernements des États et locaux. Cependant, les tribunaux américains citent de plus en plus WCAG 2.2 dans les contentieux liés à l’accessibilité, et la trajectoire est claire. Attendre un mandat fédéral formel avant d’agir est une stratégie de conformité qui comporte un risque juridique croissant, en particulier pour les organisations de e-commerce, de services financiers et de santé, qui sont des cibles de choix pour les litiges en accessibilité.

Même si votre organisation n’est pas encore légalement tenue de se conformer à WCAG 2.2, respecter les nouveaux critères de succès tôt plutôt que tard vous permettra de garder une longueur d’avance sur l’évolution des réglementations — et, plus important encore, sur les véritables obstacles d’accessibilité auxquels vos utilisateurs sont confrontés aujourd’hui.

Comment auditer et mettre à jour votre site

Si vous êtes déjà conforme à WCAG 2.1 AA, le chemin de mise à niveau vers WCAG 2.2 est gérable. Voici un cadre pratique pour l’aborder.

Commencez par un audit ciblé des six nouveaux critères de niveau AA. Ce sont ceux qui ont un poids juridique pour la plupart des organisations. Concentrez-vous en particulier sur 2.4.11 et 2.4.12 (focus masqué), 2.5.8 (taille de cible), 3.2.6 (aide cohérente), 3.3.7 (saisie redondante) et 3.3.8 (authentification accessible). Un·e ingénieur·e en accessibilité expérimenté·e peut généralement auditer ces critères manuellement en quelques heures pour un site de complexité modérée.

Auditez d’abord vos éléments fixes/en position sticky. Les critères de focus masqué (2.4.11 et 2.4.12) sont violés par certains des modèles d’interface les plus courants sur le web — en-têtes fixes, boutons d’action flottants, barres de consentement aux cookies et widgets de chat. Parcourez l’ensemble de votre site en utilisant uniquement la touche Tab et observez si un élément focalisé disparaît jamais sous une couche fixe. Une correction CSS est généralement simple :

/* Empêcher l’en-tête fixe de couvrir les éléments focalisés */
:focus {
  scroll-margin-top: 80px; /* correspond à la hauteur de votre en-tête fixe */
}

Auditez la taille de la zone de tap de chaque élément interactif. C’est souvent un gain rapide en termes de conformité et d’expérience utilisateur. Les boutons, liens, contrôles de formulaire et icônes ont tous besoin d’un minimum de 24×24 pixels CSS. De nombreux design systems dépassent déjà ce seuil, mais les petits boutons d’icône — icônes de fermeture, boutons de partage social et liens d’action en ligne — sont des contrevenants fréquents. Inspectez vos composants et ajoutez du padding ou ajustez les dimensions si nécessaire.

Examinez attentivement vos parcours d’authentification. Le critère 3.3.8 (Accessible authentication) a un impact réel. Si vous utilisez un CAPTCHA qui ne peut pas être contourné ou résolu via une méthode alternative, vous êtes probablement non conforme. Évaluez si vos parcours de connexion, d’inscription et d’authentification à deux facteurs permettent aux gestionnaires de mots de passe de préremplir, autorisent le copier-coller, offrent une méthode de vérification alternative (comme un lien magique ou un code à usage unique) ou fournissent toute autre aide aux utilisateurs qui ne peuvent pas accomplir un défi cognitif.

Auditez les formulaires multi-étapes pour la saisie redondante. Cartographiez tous les processus qui s’étendent sur plusieurs étapes — paiements, parcours d’onboarding, demandes — et identifiez chaque instance où l’on demande à un utilisateur de fournir des informations qu’il a déjà fournies. Ajoutez une logique de préremplissage ou un bouton « même que ci-dessus » lorsque c’est pertinent. Il s’agit généralement d’un changement de back-end ou de gestion d’état de formulaire plutôt que d’une refonte architecturale complexe.

Vérifiez que les mécanismes d’aide sont positionnés de manière cohérente. Si vous avez un widget de chat, un lien d’aide ou un numéro de téléphone qui apparaît dans un pied de page ou une barre latérale sur plusieurs pages, vérifiez que sa position relative ne change pas. Il s’agit généralement d’un problème de gabarit ou de mise en page plutôt que d’un problème page par page — corrigez-le dans votre bibliothèque de composants ou votre gabarit de CMS et la correction se propage partout.

Utilisez des outils automatisés pour la découverte initiale, mais ne vous arrêtez pas là. Les scanners automatisés peuvent détecter environ 40 % des problèmes WCAG 2.2 — ils sont utiles pour repérer les violations de taille de cible et les problèmes évidents de gestion du focus, mais ils ne peuvent pas évaluer si un CAPTCHA est la seule option d’authentification ou si un mécanisme d’aide est positionné de manière cohérente. Les tests manuels, y compris la navigation au clavier uniquement et les tests avec lecteur d’écran, restent essentiels. Les tests avec de vrais utilisateurs en situation de handicap mettront en évidence des problèmes qu’aucun outil automatisé ne détectera jamais.

WCAG 2.2 et les widgets d’overlay : ce qu’il faut savoir

Les widgets et SDK d’overlay d’accessibilité — des outils comme Accsible — peuvent apporter une aide significative pour mettre en évidence et corriger certaines catégories de problèmes d’accessibilité, en particulier pour les utilisateurs qui ont besoin d’ajustements en temps réel comme l’augmentation de la taille de la police, des changements de contraste ou des améliorations de la navigation au clavier. Il est utile d’être lucide sur ce que les overlays peuvent et ne peuvent pas faire dans le contexte de la conformité à WCAG 2.2.

Les overlays peuvent aider à traiter certains problèmes de visibilité du focus, fournir des modes de navigation alternatifs et offrir une personnalisation côté utilisateur qui compense certaines lacunes au niveau du design. Ils constituent une couche utile de la pile d’accessibilité, en particulier pour les équipes qui doivent améliorer rapidement l’expérience utilisateur pendant que des travaux de remédiation à plus long terme sont en cours. Cependant, ils ne remplacent pas la correction du code sous-jacent. Les nouveaux critères WCAG 2.2 — en particulier ceux concernant l’authentification (3.3.8), la saisie redondante (3.3.7) et les mouvements de glisser (2.5.7) — exigent des changements structurels dans la manière dont votre application est construite, et pas seulement dans la manière dont elle est présentée.

L’approche la plus efficace combine un overlay bien implémenté pour l’adaptabilité côté utilisateur avec des corrections appropriées au niveau du code pour les nouveaux critères 2.2. Considérez un SDK d’overlay comme un multiplicateur de force : il étend votre portée, améliore l’expérience pour davantage d’utilisateurs et comble des lacunes — mais les fondations doivent tout de même être solides.

Points clés à retenir

• WCAG 2.2 ajoute neuf nouveaux critères de succès et supprime une règle obsolète (4.1.1 Parsing). Il est entièrement rétrocompatible avec 2.1, donc votre travail de conformité existant n’est pas perdu — vous n’avez qu’à ajouter ce qui est nouveau.
• Pour la conformité de niveau AA, concentrez-vous sur six nouveaux critères spécifiques : Focus not obscured (2.4.11 et 2.4.12), Target size minimum (2.5.8), Consistent help (3.2.6), Redundant entry (3.3.7) et Accessible authentication (3.3.8). Ce sont ceux qui sont juridiquement pertinents pour la plupart des organisations.
• L’adoption réglementaire s’accélère. Le secteur public britannique applique déjà WCAG 2.2, l’UE est en train d’y passer dans le cadre de l’European Accessibility Act, et les tribunaux américains s’y réfèrent de plus en plus. N’attendez pas un mandat formel dans votre juridiction avant d’agir.
• Les outils automatisés ne détectent qu’environ 40 % des problèmes WCAG 2.2 — les tests manuels, les parcours de navigation au clavier uniquement et les tests avec de vrais utilisateurs sont essentiels pour atteindre une conformité réelle, en particulier pour les nouveaux critères concernant l’authentification et l’accessibilité cognitive.
• Les gains rapides les plus courants sont la correction des en-têtes fixes qui masquent les éléments focalisés, l’agrandissement des petites zones de tap et l’audit de vos parcours de connexion/authentification pour la dépendance aux CAPTCHA. Ces changements sont souvent peu coûteux et à fort impact — un bon point de départ pour votre sprint de remédiation WCAG 2.2.