WCAG 2.1 face aux WCAG 2.2 : ce qui a changé et pourquoi cela compte

Les WCAG 2.2 ne remplacent pas les WCAG 2.1, elles les prolongent. Elles ajoutent neuf nouveaux critères de succès (six de niveau AA), suppriment un critère devenu obsolète du fait des navigateurs modernes, et conservent intact tout le reste des WCAG 2.1, si bien qu’un site déjà conforme aux 2.1 AA n’a qu’un écart court et précis à combler, plutôt qu’un audit complet à mener.

Pourquoi deux versions des WCAG coexistent actuellement

Le W3C a publié les WCAG 2.2 en octobre 2023. Mais la plupart des cadres juridiques et réglementaires évoluent plus lentement que les organismes de normalisation qui les définissent, si bien que de nombreuses obligations de conformité actives, y compris la norme technique harmonisée EN 301 549 de l’EAA, citent toujours les WCAG 2.1 AA dans leur version actuellement publiée plutôt que les 2.2. C’est pourquoi les deux versions restent pertinentes en 2026 : les 2.2 constituent la norme la plus récente et la plus complète, mais les 2.1 sont fréquemment celles réellement nommées dans la loi.

Ce décalage est normal dans la façon dont les normes techniques et la législation interagissent. Une réglementation nomme généralement une version datée et précise d’une norme plutôt que « la version actuelle, quelle qu’elle soit », en partie pour la sécurité juridique et en partie parce que mettre à jour les références techniques d’une loi suit son propre processus administratif. La norme EN 301 549 devrait à terme intégrer les WCAG 2.2 dans une future version (la version v4.1.1 est celle généralement attendue pour ce changement), mais tant que cette mise à jour n’est pas formellement adoptée et référencée par la réglementation, les WCAG 2.1 AA restent la version à laquelle se mesure réellement la plupart du travail de conformité dans l’UE.

Ce qui est nouveau dans les WCAG 2.2

Les nouveaux critères de succès se regroupent autour de quelques thèmes pratiques plutôt que d’être répartis au hasard dans la spécification.

La visibilité du focus reçoit trois ajouts liés : le critère 2.4.11 Focus non masqué (minimum), qui exige qu’au moins une partie d’un élément recevant le focus reste visible lorsqu’un élément comme un en-tête collant ou une bannière de cookies le recouvrirait sinon, ainsi que les critères associés 2.4.12 (version renforcée, AAA) et 2.4.13 Apparence du focus (AAA), qui fixent des exigences minimales de taille et de contraste pour les indicateurs de focus.

L’authentification reçoit un ajout significatif : le critère 3.3.8 Authentification accessible (minimum), qui exige que les processus de connexion ne reposent pas uniquement sur un test de fonction cognitive (comme se souvenir d’un mot de passe ou résoudre une énigme) sans alternative, sauf si ce test relève par exemple de la reconnaissance d’objets ou bénéficie d’une aide.

L’interaction et les cibles de saisie reçoivent deux ajouts : le critère 2.5.7 Mouvements de glissement, qui exige une alternative aux interactions basées sur le glissement, et le critère 2.5.8 Taille de la cible (minimum), qui fixe une taille minimale de 24 par 24 pixels pour les cibles cliquables, sauf exceptions.

Les ajouts restants couvrent des mécanismes d’aide cohérents (3.2.6 Aide cohérente, exigeant qu’une option d’aide comme un lien de contact ou une fonction de chat apparaisse au même emplacement relatif sur les pages où elle est proposée), la saisie redondante (3.3.7 Saisie redondante, évitant de demander aux utilisateurs de ressaisir une information déjà fournie plus tôt dans le même processus, comme retaper une adresse de livraison déjà saisie à une étape précédente), et la navigation par saut de page (2.4.13, niveau AAA, destiné aux contenus paginés comme un livre numérique ou un long document).

Deux autres ajouts de niveau AA complètent la liste : le critère 2.4.11 a une version renforcée de niveau AAA, et la liste complète au niveau AA compte précisément six nouveaux critères que la plupart des programmes de conformité devront réellement vérifier : Focus non masqué (minimum), Mouvements de glissement, Taille de la cible (minimum), Aide cohérente, Saisie redondante, et Authentification accessible (minimum).

Ce qui a été supprimé

Les WCAG 2.2 ont retiré le critère 4.1.1 Analyse syntaxique, l’ancienne exigence relative au HTML bien formé (pas d’identifiants dupliqués, des balises correctement imbriquées, etc.). Les navigateurs et technologies d’assistance modernes gèrent le HTML mal formé de façon suffisamment robuste pour que ce critère n’apporte plus de valeur réelle, il a donc été retiré plutôt que conservé.

Quels nouveaux critères comptent le plus en pratique

Les neuf ajouts n’ont pas tous le même poids pour un site d’entreprise type. Focus non masqué (2.4.11) est sans doute le plus largement pertinent, car les barres de navigation collantes, les bannières de consentement aux cookies et les widgets de chat qui recouvrent l’indicateur de focus clavier constituent un problème extrêmement courant en pratique, pas un cas marginal. Taille de la cible (2.5.8) compte beaucoup pour les sites à forte utilisation mobile avec de petites cibles tactiles. Authentification accessible (3.3.8) compte surtout pour tout ce qui comporte un parcours de connexion, en particulier si ce parcours utilise des CAPTCHA ou des défis basés sur la mémoire sans alternative.

Saisie redondante (3.3.7) tend à compter surtout pour les processus en plusieurs étapes : un paiement qui demande une adresse de livraison puis redemande la même adresse à une étape de facturation, sans proposer de réutiliser la saisie précédente, est un schéma assez courant que ce critère cible spécifiquement. Mouvements de glissement (2.5.7) compte de façon disproportionnée pour les sites dotés d’éléments interactifs personnalisés comme des curseurs d’image, des listes triables ou des interfaces de carte, car l’interaction uniquement par glissement a historiquement été courante dans ces composants, sans beaucoup de réflexion accordée à une alternative sans glissement.

Faut-il refaire votre audit

Si un site est déjà conforme aux WCAG 2.1 AA, passer aux 2.2 ne signifie pas repartir de zéro. Comme les 2.2 sont rétrocompatibles, le travail pratique consiste à vérifier le site spécifiquement au regard des neuf nouveaux critères, pas à retester tout ce qui avait déjà été vérifié sous les 2.1. Les outils de test construits autour du moteur axe-core, comme ceux de Deque, ont mis à jour leurs jeux de règles pour couvrir les ajouts des 2.2, ce qui rend cette vérification bien plus rapide qu’un audit complet. Les éditeurs proposant un suivi continu, comme la plateforme d’AudioEye combinant automatisation et revue humaine, peuvent aussi signaler où un site auparavant conforme présente désormais des écarts par rapport aux nouveaux critères.

Un ordre d’opérations pratique : lancez d’abord un scan automatisé avec un jeu de règles à jour pour les 2.2, afin de détecter ce qui est mécaniquement identifiable, comme des cibles tactiles trop petites ou une incohérence des liens d’aide, puis réalisez un passage manuel ciblé sur les critères qui demandent un jugement humain, en particulier Focus non masqué et Authentification accessible, car les deux dépendent de la façon dont un vrai utilisateur vit la page plutôt que de quelque chose qu’un scan statique peut entièrement évaluer.

Où les sites échouent le plus souvent sur les nouveaux critères

Quelques schémas reviennent régulièrement lorsque des sites sont vérifiés pour la première fois au regard des 2.2. Les en-têtes collants et les widgets de chat flottants qui recouvrent l’anneau de focus clavier lorsqu’un utilisateur navigue par tabulation constituent sans doute le nouvel échec le plus courant, précisément parce que c’est un schéma de design moderne extrêmement répandu. Les parcours de connexion et d’inscription qui reposent sur un CAPTCHA sans méthode de vérification alternative échouent directement au critère Authentification accessible. Les sites e-commerce dotés d’interactions basées sur le glissement, comme un panier réordonnable par glissement ou un carrousel d’images contrôlé uniquement par glissement, échouent au critère Mouvements de glissement en l’absence de bouton ou d’alternative tactile. Et les icônes de navigation mobile ou les boutons de fermeture nettement plus petits que le minimum de 24 pixels constituent un échec fréquent au critère Taille de la cible, en particulier sur des sites conçus d’abord pour le bureau puis adaptés au mobile après coup.

Quelle version viser

Si votre loi ou votre contrat applicable nomme spécifiquement les WCAG 2.1 AA, s’y conformer reste votre exigence légale de base, et vous pouvez considérer la conformité aux 2.2 comme une amélioration tournée vers l’avenir plutôt qu’une obligation immédiate. Si vous avez de la flexibilité, ou si vous construisez quelque chose de nouveau, viser directement les 2.2 AA dès le départ est le choix le plus pérenne, puisqu’elles constituent un sur-ensemble strict des 2.1 AA, moins un critère obsolète. Dans tous les cas, notre checklist WCAG 2.1 AA est une référence de départ utile si vous n’avez pas encore audité votre site au regard de cette base.

Pour la plupart des entreprises, la réponse pratique finit par être « les deux, en séquence » : traitez les WCAG 2.1 AA comme le plancher dont vous êtes légalement responsable aujourd’hui, et ajoutez les critères des WCAG 2.2 par-dessus comme un projet d’amélioration à court terme plutôt que comme une initiative distincte. Comme les deux normes se recoupent presque entièrement, il y a peu de raisons de les cloisonner dans des audits ou des engagements fournisseurs séparés. Un seul passage de test couvrant l’ensemble des critères des 2.2 couvre automatiquement aussi les 2.1 AA, ce qui est souvent la façon la plus efficace d’aborder la question, même si votre obligation légale immédiate ne porte que sur l’ancienne version.

Suivre les futures versions des WCAG

L’historique des versions des WCAG suggère que ce schéma se répétera. Les 2.0 ont constitué la référence pendant des années, les 2.1 ont ajouté des considérations mobiles et de basse vision, et les 2.2 ont ajouté les critères décrits ci-dessus ; des WCAG 3.0 sont en développement avec une structure substantiellement différente, bien qu’elles restent un brouillon de travail plutôt qu’une norme finalisée, et l’adoption dans la loi tend à accuser un retard significatif par rapport à la publication, quelle que soit la version. La conclusion pratique pour une entreprise n’est pas de courir après chaque nouveau brouillon, mais d’intégrer une vérification périodique à son processus d’accessibilité (une fois par an est raisonnable pour la plupart des sites), afin que, lorsqu’une nouvelle version devient réellement pertinente, que ce soit par une réglementation mise à jour ou une véritable bonne pratique, vous ne partiez pas de zéro pour savoir où vous en êtes.