WCAG 2.2 : les 9 nouveaux critères expliqués simplement

Une personne qui navigue au clavier parcourt votre tunnel de commande avec la touche Tab. Le focus arrive sur le bouton « Payer maintenant », mais un bandeau cookies fixe le recouvre : elle ne voit plus où elle se trouve. Avec les WCAG 2.1, cette page pouvait encore passer. Avec les WCAG 2.2, elle échoue.

C'est ce genre de lacune que comble la version 2.2. Ci-dessous, chaque nouveau critère de succès est traité de la même façon : ce qu'il dit, à qui il sert, un test rapide et la correction habituelle. Pour les quatre principes et les niveaux sur une seule page, consultez notre référence WCAG 2.2.

Que sont les WCAG 2.2 ?

Les WCAG 2.2 sont la version actuelle des Règles pour l'accessibilité des contenus web (Web Content Accessibility Guidelines), la norme du W3C à laquelle renvoient la plupart des lois et des contrats sur l'accessibilité. Elles sont devenues une recommandation du W3C le 5 octobre 2023 (s'ouvre dans un nouvel onglet), ont été mises à jour le 12 décembre 2024 (s'ouvre dans un nouvel onglet) et ont été approuvées comme norme ISO/IEC 40500:2025 (s'ouvre dans un nouvel onglet) en octobre 2025.

Les WCAG se composent d'exigences vérifiables appelées critères de succès, chacun associé à un niveau : A (le minimum), AA (ce que demandent généralement les lois) ou AAA (le plus exigeant). « Il nous faut les WCAG 2.2 AA » signifie tous les critères A et AA de la version 2.2. D'après la traduction française agréée, les WCAG 2.2 « ont été développées à partir des WCAG 2.1 et sont rétrocompatibles avec elles » : elles complètent la version 2.1 au lieu de la remplacer.

Qu'est-ce qui a changé entre les WCAG 2.1 et 2.2 ?

Les WCAG 2.2 ajoutent neuf critères de succès et en suppriment un. Six des nouveaux sont de niveau A ou AA et comptent donc pour l'objectif habituel AA : 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 et 3.3.8. Les trois autres sont de niveau AAA. Le critère supprimé est le 4.1.1 Analyse syntaxique, que le W3C qualifie désormais d'obsolète.

Le 4.1.1 Analyse syntaxique vérifiait les erreurs de balisage, comme les identifiants en double. La FAQ des WCAG 2 (s'ouvre dans un nouvel onglet) explique que ces problèmes relèvent désormais d'autres critères, comme le 4.1.2 Nom, rôle et valeur. Une réserve : si un contrat exige encore les WCAG 2.0 ou 2.1, vous devrez peut-être « continuer à tester le critère 4.1.1 et à en rendre compte ».

Focus non masqué et apparence du focus : voit-on où l'on se trouve au clavier ?

Ces critères gardent visible l'élément qui a le focus clavier. Au niveau AA (2.4.11), un lien ou un bouton qui reçoit le focus ne doit pas être entièrement caché par un contenu que vous avez ajouté, comme un en-tête fixe, un bandeau cookies ou une bulle de chat. Au niveau AAA, rien ne doit en masquer la moindre partie (2.4.12), et le contour du focus doit être grand et nettement contrasté (2.4.13).

• À qui ils servent : aux personnes voyantes qui utilisent un clavier plutôt qu'une souris, souvent en raison d'un handicap moteur. Si elles ne voient pas le focus, elles avancent à l'aveugle.
• Test rapide : chargez une longue page avec le bandeau cookies, l'en-tête fixe et le widget de chat affichés, puis appuyez plusieurs fois sur Tab. Si le focus disparaît complètement derrière un élément, c'est un défaut au regard du 2.4.11.
• Correction habituelle : ajoutez en CSS un scroll-padding égal à la hauteur de votre en-tête ou pied de page fixe, pour que le navigateur fasse défiler les éléments qui reçoivent le focus hors de leur portée. Le W3C la cite parmi les techniques suffisantes (s'ouvre dans un nouvel onglet). Un bandeau peut aussi être conforme s'il est modal et doit être fermé en premier.

L'apparence du focus (2.4.13) demande un indicateur au moins aussi grand qu'un contour de 2 pixels CSS d'épaisseur autour du composant, avec un changement de contraste d'au moins 3:1 entre l'état avec focus et sans focus. C'est un critère AAA, mais un contour plein de 2 pixels dans une couleur franche suffit généralement. Notre guide sur le contraste des couleurs explique comment mesurer un rapport de 3:1.

Mouvements de glissement et taille de la cible : votre site s'utilise-t-il sans pointage précis ?

Ces deux critères de niveau AA aident les personnes qui ont du mal à contrôler finement un pointeur. Le 2.5.7 exige que tout ce qui se fait en faisant glisser fonctionne aussi par de simples clics ou touchers. Le 2.5.8 exige que les cibles mesurent au moins 24 sur 24 pixels CSS, ou soient espacées de sorte qu'un cercle de 24 pixels centré sur chacune ne touche aucune autre cible.

2.5.7 Mouvements de glissement

Pensez au curseur de fourchette de prix dans les filtres d'une boutique, ou à une liste d'envies qu'on réordonne par glisser-déposer. Pour une personne qui a des tremblements, ou qui utilise un pointeur frontal, appuyer, maintenir, déplacer puis relâcher peut être très difficile.

Test rapide : réalisez chaque action de glissement uniquement par clics ou touchers. Correction habituelle : permettez de cliquer n'importe où sur la piste du curseur, ajoutez à côté des champs « min » et « max », ou des boutons « Monter » et « Descendre » dans les listes triables. Le clavier seul ne suffit pas : le document explicatif (s'ouvre dans un nouvel onglet) du W3C précise qu'un équivalent clavier « ne satisfait pas automatiquement ce critère de succès ».

2.5.8 Taille de la cible (minimum)

Les défauts habituels : les petits boutons « × » des fenêtres pop-up, les numéros de page serrés, les notes en étoiles et les rangées d'icônes de réseaux sociaux. Toucher la mauvaise cible agace tout le monde, et constitue un vrai obstacle pour les personnes dont la dextérité est limitée.

• Exceptions : les liens au sein d'une phrase, les cibles qui ont ailleurs sur la page un équivalent de taille suffisante, les contrôles dimensionnés par le navigateur dont vous n'avez pas modifié le style, et les cas où une taille donnée est essentielle ou imposée par la loi.
• Test rapide : sur un téléphone, essayez chaque petite icône et chaque petit bouton ; pour en mesurer un, inspectez-le avec les outils de développement de votre navigateur.
• Correction habituelle : ajoutez du padding. La zone cliquable s'agrandit même si l'icône ne change pas. Et considérez 24 pixels comme un plancher : l'ancien critère AAA 2.5.5 demande 44 sur 44.

Aide cohérente et saisie redondante : obligez-vous les gens à chercher ou à se répéter ?

Les deux sont de niveau A. Le 3.2.6 Aide cohérente exige que, si une aide comme des coordonnées, un chat ou un lien vers une FAQ apparaît sur plusieurs pages, elle se trouve à chaque fois dans le même ordre par rapport au reste de la page. Le 3.3.7 Saisie redondante exige qu'on n'ait pas à retaper une information déjà donnée au cours du même processus.

L'aide cohérente ne vous oblige pas à proposer de l'aide. Elle dit seulement que si le numéro de téléphone figure dans l'en-tête des fiches produit, il ne doit pas passer dans le pied de page au moment du paiement, là où l'on en a le plus besoin. Les personnes qui ont des troubles de la mémoire ou de l'attention en profitent le plus. La correction passe généralement par un gabarit commun plutôt que par un placement page par page.

La saisie redondante vise les formulaires en plusieurs étapes. Un formulaire de réservation qui demande votre e-mail à l'étape 1 puis à nouveau à l'étape 3 échoue, tout comme un tunnel de commande qui vous fait retaper une adresse de facturation identique. Remplissez le champ automatiquement ou laissez la personne le sélectionner, par exemple avec une case « L'adresse de facturation est identique à l'adresse de livraison ». Exceptions : lorsque la nouvelle saisie est indispensable ou nécessaire à la sécurité, ou lorsque l'information précédente n'est plus valable.

Authentification accessible : peut-on se connecter sans test de mémoire ?

Le critère de succès 3.3.8 (niveau AA) exige qu'aucune étape de la connexion ne repose sur un test cognitif, comme se souvenir d'un mot de passe, recopier des caractères déformés ou résoudre une énigme, sauf si vous proposez une alternative ou une aide. En pratique : laissez les gestionnaires de mots de passe remplir les champs, autorisez le collage et proposez une méthode qui ne dépend pas de la mémoire.

Les WCAG définissent le test cognitif comme « une tâche qui demande à l'utilisateur de mémoriser, manipuler ou retranscrire une information ». Saisir son nom, son adresse e-mail ou son numéro de téléphone ne compte pas, car ces informations sont propres à chacun et identiques partout. Une étape de connexion est conforme au niveau AA si elle propose au moins l'un des éléments suivants :

• Une alternative sans test cognitif, comme une clé d'accès (passkey) ou un lien envoyé par e-mail.
• Un mécanisme d'aide, comme la prise en charge des gestionnaires de mots de passe, ou le copier-coller pour ne pas avoir à retaper un code à usage unique.
• La reconnaissance d'objets, par exemple « sélectionnez les images contenant un vélo ».
• Des contenus personnels, comme reconnaître une image que vous avez vous-même téléversée.

La version AAA, le 3.3.9, supprime les deux dernières options : un CAPTCHA à images peut donc passer au niveau AA mais pas au niveau AAA. Défauts typiques : des champs de mot de passe qui bloquent le collage ou les gestionnaires de mots de passe, des cases de code à usage unique qui se bloquent quand on y colle le code, et un CAPTCHA textuel sans alternative. Les personnes dyslexiques ou ayant des troubles de la mémoire y gagnent le plus, mais quiconque s'est retrouvé bloqué après une longue journée reconnaîtra le problème.

Les WCAG 2.2 sont-elles obligatoires ?

Tout dépend du pays et du type d'organisation. Les lois citent rarement une version des WCAG, et plusieurs renvoient encore aux WCAG 2.1 AA. Comme les WCAG 2.2 sont rétrocompatibles, respecter le niveau AA des 2.2 revient à respecter celui des 2.1, hormis le 4.1.1 supprimé. Viser les 2.2 couvre donc les deux. Si un contrat cite une version, suivez le contrat.

• Union européenne : au titre de l'acte européen sur l'accessibilité, la conformité est présumée lorsque vous respectez la norme harmonisée EN 301 549. Selon AccessibleEU (s'ouvre dans un nouvel onglet), la version 4.1.1, publiée en septembre 2026, intègre les WCAG 2.2 mais n'est pas encore la référence légale ; tant qu'elle n'est pas citée au Journal officiel, c'est la v3.2.1 (fondée sur les WCAG 2.1 AA) qui s'applique. En France, le secteur public et les entreprises d'au moins 250 millions d'euros de chiffre d'affaires relèvent en outre du RGAA, le référentiel général d'amélioration de l'accessibilité. Notre guide sur l'European Accessibility Act explique à qui s'applique le texte.
• Royaume-Uni : les recommandations du gouvernement (s'ouvre dans un nouvel onglet) indiquent que les sites et applis du secteur public doivent respecter les WCAG 2.2 AA. Elles visent les organismes publics, pas les entreprises privées.
• États-Unis : la règle du ministère de la Justice pour les administrations des États et les collectivités locales s'appuie sur les WCAG 2.1 AA, avec des échéances repoussées en avril 2026 (s'ouvre dans un nouvel onglet) au 26 avril 2027 et au 26 avril 2028. Pour les entreprises privées, les recommandations de 2022 (s'ouvre dans un nouvel onglet) du ministère indiquent que l'ADA s'applique à leurs sites web, sans fixer de norme technique précise.

Et les WCAG 3 ?

Les WCAG 3 sont un brouillon : personne ne peut encore s'y conformer. Le W3C en a publié des versions de travail mises à jour en septembre 2026 et indique qu'elles ne devraient pas devenir une norme achevée avant « encore quelques années ». Les WCAG 2 resteront ensuite en vigueur plusieurs années encore : la version 2.2 est donc celle sur laquelle travailler aujourd'hui.

Comment vérifier les nouveaux critères en 15 minutes ?

Vous repérerez la plupart des défauts sur les six critères A et AA en 15 minutes environ, avec un clavier, un téléphone et votre propre page de connexion. Cela ne remplace ni un audit complet ni des tests avec des personnes handicapées, mais vous saurez par où commencer et un développeur aura une liste concrète à traiter.

1. Parcourez avec Tab votre page d'accueil, une fiche produit et votre tunnel de commande, tous les bandeaux affichés. Voyez-vous toujours le focus ? (2.4.11)
2. Réalisez chaque action de curseur ou de glisser-déposer uniquement par clics ou touchers. (2.5.7)
3. Sur un téléphone, essayez chaque bouton de fermeture, numéro de page et petite icône. (2.5.8)
4. Comparez l'emplacement de l'aide et des coordonnées sur trois types de pages. (3.2.6)
5. Faites un achat ou une réservation et notez chaque question à laquelle vous répondez deux fois. (3.3.7)
6. Connectez-vous avec un gestionnaire de mots de passe, puis collez un mot de passe et un code à usage unique. Chaque CAPTCHA a-t-il une alternative ? (3.3.8)

Pour le reste des WCAG, notre guide pour tester l'accessibilité de votre site présente les outils gratuits et les vérifications manuelles, et notre check-list d'accessibilité web transforme les défauts courants en liste de tâches. Ce que vous ne pouvez pas encore corriger a sa place dans votre déclaration d'accessibilité.

Un mot sur les widgets, le nôtre compris : aucun de ces critères ne peut être satisfait par un panneau côté visiteur. Un grand curseur aide à viser les petites cibles, mais ne les rend pas larges de 24 pixels, et surligner le focus ne déplace pas un bandeau fixe. Chaque nouveau critère porte sur la façon dont vos pages sont construites : la correction se trouve dans vos gabarits et votre code.