QualiBooth

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.

7 min read QualiBooth
Art numérique abstrait représentant la surveillance continue de l'accessibilité et les contrôles de conformité WCAG.

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èreNiveauThème
2.4.11 Focus non masqué (min.)AAFocus clavier
2.4.12 Focus non masqué (amélioré)AAAFocus clavier
2.4.13 Apparence du focusAAIndicateur de focus
2.5.7 Mouvements de glissementAASaisie au pointeur
2.5.8 Taille de la cible (minimum)AACibles tactiles
3.2.6 Aide constanteAPrévisibilité
3.3.7 Saisie redondanteAFormulaires
3.3.8 Authentification accessible (min.)AAConnexion / CAPTCHA
3.3.9 Authentification accessible (amélioré)AAAConnexion / CAPTCHA
4.1.1 Analyse syntaxiqueASupprimé

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 ?