Ce qui a changé dans WCAG 2.2 par rapport à WCAG 2.1

Les Web Content Accessibility Guidelines (WCAG) sont la norme que la plupart des lois d'accessibilité visent. WCAG 2.2 est devenue Recommandation W3C le 5 octobre 2023, a ajouté neuf nouveaux critères de succès et en a retiré un. C'est désormais aussi ISO/IEC 40500:2025. Si vous maintenez un site, un design system ou un produit en 2026, la question pratique est : qu'a changé, qu'exige chaque nouveau critère, et comment prioriser les correctifs ? Ce billet répond à chacun, sources citées pour vérification.

Brève histoire de WCAG

Le W3C a publié les premières Web Content Accessibility Guidelines le 5 mai 1999. WCAG 1.0 était prescriptive et spécifique à HTML ; elle a vieilli vite quand le web est passé des documents plats aux applications riches.

WCAG 2.0 est arrivée le 11 décembre 2008. Elle a abstrait les recommandations d'une technologie particulière, les a organisées sous les quatre principes « Perceptible, Utilisable, Compréhensible, Robuste » (POUR), et a introduit le schéma de conformité à trois niveaux A/AA/AAA encore utilisé. C'est la version que la plupart des réglementations américaines et internationales référençaient à l'origine.

WCAG 2.1 a suivi le 5 juin 2018. Elle a ajouté 17 nouveaux critères couvrant le mobile (orientation, cibles tactiles, déclenchement par mouvement), les utilisateurs malvoyants (reflow, espacement de texte, contraste non-textuel) et l'accessibilité cognitive (label-in-name, messages de statut). C'est la version intégrée au standard EN 301 549 v3.2.1 référencé par l'European Accessibility Act.

WCAG 2.2 a été publiée le 5 octobre 2023 et republiée avec des mises à jour éditoriales le 12 décembre 2024. Elle ajoute neuf nouveaux critères, en retire un (4.1.1 Parsing) et est désormais aussi ISO/IEC 40500:2025. WCAG 3, un cadre substantiellement différent avec un nouveau scoring, est encore en brouillon, pas attendu pour adoption générale avant 2027.

Les neuf nouveaux critères de succès

Les nouveaux critères tombent en trois groupes thématiques : focus, modalité d'entrée, accessibilité cognitive.

Groupe focus

2.4.11 Focus Non Occulté (Minimum), Niveau AA. Quand un composant d'interface reçoit le focus clavier, il ne doit pas être entièrement caché par du contenu auteur (barres collantes, bannières cookies, widgets de chat). Le composant peut être partiellement occulté ; le critère n'échoue que quand rien n'est visible.

2.4.12 Focus Non Occulté (Renforcé), Niveau AAA. Version plus stricte de 2.4.11 : aucune partie du composant focalisé ne doit être cachée. Version AAA visée par la plupart des design systems d'entreprise.

2.4.13 Apparence du Focus, Niveau AAA. L'indicateur de focus doit faire au moins 2 pixels CSS d'épaisseur autour du contrôle focalisé, et son contraste contre l'état non-focalisé adjacent doit être au moins 3:1. Un anneau de focus 1px par défaut sur un bouton sombre échoue ; un anneau 2px à fort contraste passe.

Groupe modalité d'entrée

2.5.7 Mouvements de Glisser, Niveau AA. Tout ce qui peut se faire avec un geste de glisser doit aussi être possible sans. Exemples : listes triables qui ne répondent qu'au glisser, curseurs qui ne répondent qu'au glisser, panoramique de carte exigeant le glisser. Le critère n'interdit pas le glisser ; il exige une alternative comme flèches haut/bas pour réordonner, ou champ de saisie pour valeur de curseur.

2.5.8 Taille de Cible (Minimum), Niveau AA. Les cibles de pointeur doivent faire au moins 24 par 24 pixels CSS, sauf si elles sont en ligne (liens dans un paragraphe), exposées dans un défaut du user-agent (un <select>), essentielles à la fonction, ou ont un contrôle équivalent ailleurs sur la page qui atteint 24x24. Le critère antérieur WCAG 2.1 2.5.5 fixait le seuil à 44x44 mais au niveau AAA ; 2.5.8 rend un plancher 24x24 plus petit obligatoire au niveau AA.

Groupe accessibilité cognitive

3.2.6 Aide Cohérente, Niveau A. Si des mécanismes d'aide (« Contactez-nous », widget chat, lien d'aide, téléphone d'aide) apparaissent sur plusieurs pages, ils doivent apparaître dans le même ordre relatif sur chaque page. L'intention est de réduire la charge cognitive.

3.3.7 Saisie Redondante, Niveau A. Les utilisateurs ne devraient pas devoir ressaisir des informations déjà saisies dans le même processus. Les formulaires multi-étapes doivent se souvenir des saisies précédentes. Le critère n'interdit pas de redemander quand c'est essentiel (vérification de sécurité) ou quand l'information a changé.

3.3.8 Authentification Accessible (Minimum), Niveau AA. L'authentification ne peut pas exiger de tests de fonction cognitive comme se souvenir d'un mot de passe, résoudre un puzzle, ou transcrire un CAPTCHA à image, sauf si une alternative est fournie. Alternatives acceptables : gestionnaire de mots de passe, code à usage unique, biométrie, jeton matériel. C'est le critère qui a mis fin au motif « tapez les lettres de cette image » pour sites accessibles.

3.3.9 Authentification Accessible (Renforcée), Niveau AAA. Version plus stricte : les puzzles de reconnaissance d'objet et de contenu personnel sont aussi interdits, sauf alternative.

Le critère retiré

4.1.1 Parsing a été retiré comme obsolète. Il exigeait que le contenu soit analysable : balises de début/fin complètes, pas d'IDs en doublon, éléments correctement imbriqués. En 2008 cela importait parce que les technologies d'assistance parsaient HTML elles-mêmes et échouaient sur le markup malformé. En 2024 chaque techno d'assistance consomme l'arbre d'accessibilité du navigateur, pas le HTML brut. WCAG 2.2 reconnaît cela en supprimant le critère. Il apparaît encore dans la conformité WCAG 2.0 et 2.1, pas dans 2.2.

Niveaux de conformité, rappel

Impact pratique, par où commencer

1. 2.5.8 Taille de Cible (Minimum), 24x24 pixels CSS. Auditer boutons, liens-icônes et petits toggles. Les contrôles plus petits que 24x24 ont besoin soit d'une zone de clic plus grande, soit de plus d'espace autour, soit d'un contrôle équivalent plus grand sur la page. Échec 2.2 le plus courant en pratique.
2. 2.4.11 Focus Non Occulté (Minimum). Chercher barres collantes en bas, footers collants, widgets de chat, bannières cookies qui recouvrent le bas du viewport. Quand un élément focalisable défile derrière l'un d'eux, le critère échoue. Correctif : scroll-margin-bottom sur les éléments focalisables égal à la hauteur de la barre collante.
3. 3.3.8 Authentification Accessible (Minimum). Retirer les CAPTCHA à image des flux de connexion ; remplacer par invisible-CAPTCHA ou approche par limitation de débit. Autoriser les gestionnaires de mots de passe (ne pas désactiver autocomplete sur les champs mot de passe). Autoriser le collage de codes à usage unique.
4. 2.5.7 Mouvements de Glisser. Fournir une alternative non-glisser pour toute interaction glisser uniquement. Listes triables : flèches haut/bas. Curseurs : entrée numérique. Cartes : boutons de panoramique.
5. 3.2.6 Aide Cohérente. Si votre lien « Contact » ou « Aide » apparaît sur plusieurs pages, positionnez-le de façon cohérente.
6. 3.3.7 Saisie Redondante. Les formulaires multi-étapes doivent se souvenir des saisies précédentes.

Pièges courants en implémentant les nouveaux critères

• Traiter 4.1.1 Parsing comme disparu partout. 4.1.1 est retiré de WCAG 2.2 mais reste exigé par WCAG 2.0 et 2.1. Si votre contrat ou règlement spécifie 2.1, la règle parsing s'applique toujours.
• Mal lire 2.5.8 Taille de Cible. Le minimum 24x24 est pour la cible, pas pour l'icône visible. Une icône 16x16 dans un bouton 24x24 passe. Une icône 16x16 dans un bouton 16x16 échoue.
• Oublier les exceptions à 2.5.8. Liens en ligne dans un paragraphe, contrôles user-agent par défaut, cibles essentielles, et contrôles équivalents plus grands ailleurs sur la page sont exemptés.
• Implémenter 3.3.8 en retirant tout CAPTCHA. Vous pouvez garder le CAPTCHA ; il faut juste un chemin alternatif accessible. Tests de Turing inverses, limites de débit, magic links, passkeys, ou jetons matériels qualifient tous.
• 2.4.11 confondu avec 2.4.13. Focus Non Occulté (2.4.11) concerne si l'élément focalisé est visible du tout. Apparence du Focus (2.4.13) concerne l'indicateur de focus lui-même qui doit être épais et contrasté. Exigences différentes à niveaux différents.
• Sauter 2.4.13 parce qu'AAA. Plusieurs gouvernements (Norvège, parties du Canada) ont adopté des règles niveau AAA pour sites du secteur public.

Outils pour vérifier la conformité WCAG 2.2

Les outils automatisés attrapent environ 30 à 40 % des échecs WCAG même au mieux. Les nouveaux critères 2.2 sont particulièrement durs à automatiser (2.5.7, 3.2.6, 3.3.7, 3.3.8) car ils exigent de comprendre le flux utilisateur, pas seulement le markup. Prévoyez un test clavier manuel à chaque release.

Confidentialité et les outils

Le vérificateur de contraste, le vérificateur de titres WCAG et le générateur de palette accessible d'Absolutool tournent tous entièrement dans votre navigateur. Le HTML ou les valeurs couleur que vous collez sont traités par JavaScript sur votre appareil, les résultats s'affichent sur la page, et rien n'est envoyé à un serveur. Pas de télémétrie sur l'entrée, pas de scripts tiers touchant le contenu, pas de cache après navigation. Pour des audits internes de design system, des couleurs de marque non sorties, ou toute donnée d'audit sous embargo, ce flux strictement local est le bon défaut. Les outils peuvent tourner hors-ligne une fois la page chargée, ce que vous pouvez vérifier en coupant le réseau et en re-vérifiant une paire de contraste.