wcag
WCAG 2.1 vs 2.2 : ce qui a changé et pourquoi c'est important
Un décryptage clair de chaque changement entre WCAG 2.1 et WCAG 2.2 — nouveaux critères de succès, ce qui a été supprimé, et ce que votre site doit corriger pour rester conforme.
WCAG 2.2 est devenue une recommandation du W3C en octobre 2023. Si votre site a été audité au regard de WCAG 2.1, il peut déjà échouer sur des critères qui définissent désormais la conformité légale dans l’UE, au Royaume-Uni et, de plus en plus, dans les actions de contrôle aux États-Unis. Ce guide passe en revue chaque changement — ce qui a été ajouté, ce qui a été supprimé, et ce que chaque critère signifie en pratique.
Rappel rapide : ce qu’a apporté WCAG 2.1
WCAG 2.1 (publiée en 2018) a étendu la norme 2.0 d’origine avec 17 nouveaux critères de succès axés sur trois groupes jusqu’alors mal servis :
- Les utilisateurs mobiles — gestes tactiles, orientation de l’écran, précision du pointeur
- Les personnes malvoyantes — redistribution, contraste du contenu non textuel, espacement du texte
- Les handicaps cognitifs et langagiers — délais d’expiration, messages d’état
WCAG 2.2 s’appuie directement sur la 2.1. Toutes les exigences de la 2.1 restent applicables. La question est : qu’a ajouté la 2.2 par-dessus ?
Ce que WCAG 2.2 a ajouté : 9 nouveaux critères de succès
2.4.11 Focus non masqué (minimum) — niveau AA
Lorsqu’un composant reçoit le focus clavier, il ne doit pas être entièrement masqué par d’autres contenus (en-têtes fixes, bandeaux cookies, widgets de chat). Une partie au moins de l’élément ayant le focus doit rester visible.
Défaillance courante : une barre de navigation fixe recouvre le champ de formulaire ayant le focus lorsqu’un utilisateur parcourt la page à la tabulation.
2.4.12 Focus non masqué (amélioré) — niveau AAA
Version plus stricte du 2.4.11 — le composant ayant le focus doit être entièrement visible, et pas seulement partiellement.
2.4.13 Apparence du focus — niveau AA
Les indicateurs de focus clavier doivent respecter des seuils minimaux de taille et de contraste :
- La zone de l’indicateur de focus doit être au moins aussi grande qu’un périmètre de 2 pixels CSS autour du composant
- Le contraste entre l’état avec focus et l’état sans focus doit être d’au moins 3:1
Cela va plus loin que le critère existant 2.4.7 (Visibilité du focus), qui exigeait seulement qu’un indicateur de focus existe.
Défaillance courante : un fin contour pointillé de 1 px à faible contraste satisfait le 2.4.7 mais échoue au 2.4.13.
2.5.7 Mouvements de glissement — niveau AA
Toute action qui exige un glissement doit également pouvoir être réalisée avec un pointeur unique (appui ou clic). Cela sert les utilisateurs ayant des handicaps moteurs qui ne peuvent pas contrôler de manière fiable les opérations de glissement.
Exemple : une liste réorganisable doit proposer une alternative (des boutons haut/bas, par exemple) pour les utilisateurs qui ne peuvent pas faire glisser les éléments.
2.5.8 Taille de la cible (minimum) — niveau AA
Les cibles interactives (boutons, liens, contrôles de formulaire) doivent mesurer au moins 24 × 24 pixels CSS — ou disposer d’un espacement suffisant par rapport aux cibles adjacentes pour que la zone d’activation totale atteigne le seuil.
Il s’agit de la version minimale. Le critère amélioré (2.5.5, repris de la 2.1 au niveau AAA) recommande 44 × 44 px.
Défaillances courantes : boutons composés uniquement d’une icône, icônes de fermeture (×) et liens textuels en ligne dans des menus de navigation serrés.
3.2.6 Aide constante — niveau A
Si un site web propose un mécanisme d’aide (numéro de téléphone, lien de chat, formulaire de contact, lien FAQ), celui-ci doit apparaître à la même position relative sur toutes les pages où il est présent. Les utilisateurs ayant des handicaps cognitifs dépendent souvent d’un placement prévisible.
3.3.7 Saisie redondante — niveau A
Une information qu’un utilisateur a déjà transmise au cours de la même session ne doit pas être redemandée — sauf si la ressaisie est essentielle (un champ de confirmation de mot de passe, par exemple) ou si la donnée est sensible sur le plan de la sécurité.
Exemple : un tunnel de paiement en plusieurs étapes ne doit pas demander l’adresse de facturation à l’étape 3 si l’utilisateur l’a déjà saisie à l’étape 1.
3.3.8 Authentification accessible (minimum) — niveau AA
Les étapes d’authentification ne doivent pas reposer sur un test de fonction cognitive — reconnaître des objets, transcrire des caractères ou résoudre des énigmes — sauf si une alternative est fournie ou si le test consiste à reconnaître un contenu contrôlé par l’utilisateur (une photo qu’il a lui-même téléversée, par exemple).
Défaillances courantes : les CAPTCHA qui exigent d’identifier du texte déformé sans alternative audio, ou les épreuves du type « cliquez sur toutes les images contenant des feux tricolores ».
3.3.9 Authentification accessible (amélioré) — niveau AAA
La version améliorée supprime même l’exception relative au contenu contrôlé par l’utilisateur. Aucun test de fonction cognitive n’est autorisé dans le parcours d’authentification.
Ce que WCAG 2.2 a supprimé : 4.1.1 Analyse syntaxique
WCAG 2.1 comportait le critère 4.1.1 Analyse syntaxique (niveau A), qui exigeait un HTML bien formé — identifiants d’éléments uniques, balises correctement imbriquées et paires complètes de balises ouvrantes et fermantes. Les navigateurs modernes sont devenus si performants pour corriger silencieusement le HTML mal formé que ce critère est devenu impossible à mesurer en pratique.
Dans WCAG 2.2, le critère 4.1.1 Analyse syntaxique est marqué comme obsolète et toujours considéré comme satisfait. Vous n’avez plus besoin de l’auditer, même si écrire du HTML propre reste une bonne pratique.
Tableau récapitulatif
| Critère | Niveau | Thème |
|---|---|---|
| 2.4.11 Focus non masqué (min.) | AA | Focus clavier |
| 2.4.12 Focus non masqué (amélioré) | AAA | Focus clavier |
| 2.4.13 Apparence du focus | AA | Indicateur de focus |
| 2.5.7 Mouvements de glissement | AA | Saisie au pointeur |
| 2.5.8 Taille de la cible (minimum) | AA | Cibles tactiles |
| 3.2.6 Aide constante | A | Prévisibilité |
| 3.3.7 Saisie redondante | A | Formulaires |
| 3.3.8 Authentification accessible (min.) | AA | Connexion / CAPTCHA |
| 3.3.9 Authentification accessible (amélioré) | AAA | Connexion / CAPTCHA |
| Supprimé |
Qui doit passer à la version supérieure ?
Pratiquement tout le monde. WCAG 2.2 constitue désormais le socle référencé par :
- L’European Accessibility Act (EAA), en vigueur depuis juin 2025
- La norme harmonisée EN 301 549 (mise à jour pour référencer WCAG 2.2)
- Le règlement britannique sur l’accessibilité des organismes du secteur public (recommandations mises à jour)
- De nombreuses lois d’États américains et les positions informelles du ministère de la Justice (DOJ) en matière de contrôle
Si votre dernier audit complet portait sur WCAG 2.1 AA, concentrez votre effort de mise à niveau sur ces cinq critères qui concernent la plupart des sites : 2.4.11, 2.4.13, 2.5.8, 3.3.8 et 3.3.7 (si vous avez des formulaires ou des tunnels de paiement en plusieurs étapes).
Comment auditer les nouveaux critères
La plupart des outils d’analyse automatisée signalent désormais le 2.5.8 (taille de la cible) et certains cas du 2.4.13 (apparence du focus). En revanche, les points suivants exigent des tests manuels :
- 2.4.11 / 2.4.12 — parcourez chaque page à la tabulation avec les en-têtes et pieds de page fixes activés et vérifiez que les éléments ayant le focus sont visibles
- 2.4.13 — mesurez les dimensions et le contraste de l’indicateur de focus avec les DevTools du navigateur ou un vérificateur de contraste
- 2.5.7 — identifiez chaque interaction par glissement et vérifiez qu’une alternative au pointeur seul existe
- 3.2.6 — vérifiez que les liens d’aide apparaissent à des positions constantes d’une page à l’autre
- 3.3.7 — parcourez tous les processus en plusieurs étapes et vérifiez qu’aucune donnée n’est demandée deux fois
- 3.3.8 — testez chaque étape de connexion, d’inscription et de vérification à la recherche de tests de fonction cognitive
WCAG 2.2 n’est pas une refonte totale — c’est un ensemble ciblé d’ajouts qui répond à des obstacles réels que la 2.1 avait manqués. La bonne nouvelle est que la plupart des nouveaux critères AA peuvent être résolus par un travail de remédiation ciblé plutôt que par une reconstruction complète du site.
À lire aussi : Rendre votre site conforme à WCAG 2.2 · Guide des audits d’accessibilité manuels
Besoin d'aide pour auditer votre site au regard de WCAG 2.2 ?