Quoi de neuf dans WCAG 2.2 : changements et mises à jour par rapport à WCAG 2.1

Les Web Content Accessibility Guidelines(opens in a new tab) (WCAG) fournissent un cadre pour créer des contenus numériques accessibles à tous les utilisateurs et conformes aux principales lois sur l’accessibilité. Suivre les WCAG permet de garantir que tout le monde peut utiliser vos contenus numériques, d’élargir votre audience et de réduire les risques juridiques. 

À mesure que le secteur de l’accessibilité et la technologie évoluent, les directives WCAG évoluent également. La dernière version, publiée en octobre 2023, fait progresser les normes d’accessibilité numérique. Ci-dessous, nous détaillons les nouveautés de WCAG 2.2 et comment appliquer ces mises à jour à vos contenus numériques.

Une série de quatre symboles d’accessibilité s’estompant au loin, sur un fond en dégradé arc-en-ciel.

Qu’est-ce que WCAG 2.2 ?

Publiées par le World Wide Web Consortium(opens in a new tab) (W3C), les WCAG sont des normes internationales qui expliquent comment rendre les sites web et les contenus numériques accessibles aux personnes en situation de handicap. Le W3C a publié pour la première fois les normes WCAG le 5 mai 1999. À mesure que les expériences numériques évoluent et se complexifient, le W3C met à jour les directives sur la base d’examens rigoureux, de nombreuses révisions et de retours du public(opens in a new tab). Depuis leur publication, le W3C a annoncé trois versions des directives, chacune s’appuyant sur la précédente.

Chaque version des WCAG contient des critères de succès organisés en trois niveaux de conformité :

• Niveau A : Le niveau minimum de conformité, le niveau A, contient des critères de base pour supprimer les obstacles majeurs à l’accessibilité qui affectent un large éventail d’utilisateurs. 

• Niveau AA : Le niveau AA supprime des obstacles supplémentaires et établit un niveau d’accessibilité qui fonctionne pour la plupart des personnes en situation de handicap et des technologies d’assistance, y compris les lecteurs d’écran. 

• Niveau AAA : Le niveau de conformité le plus strict, le niveau AAA, contient des critères supplémentaires pour établir le niveau d’accessibilité le plus élevé possible. Déclarer la conformité au niveau AAA signifie que votre site répond à tous les critères de succès des WCAG.

Icône d’accessibilité avec le label 2.1 à côté d’une icône d’accessibilité avec le label 2.2

Quelle est la différence entre WCAG 2.1 et 2.2 ?

La principale différence entre WCAG 2.1 et WCAG 2.2 est l’accent mis sur l’utilisation. Depuis octobre 2025, WCAG 2.2 est la norme d’accessibilité actuelle du W3C(opens in a new tab), et elle met davantage l’accent sur l’utilisabilité — en particulier pour la navigation au clavier, les interactions tactiles et l’accessibilité cognitive — tout en conservant les exigences existantes de WCAG 2.1.

Les nouveaux critères de succès de WCAG 2.2 répondent aux obstacles courants que les utilisateurs rencontrent encore dans les expériences numériques réelles, notamment les indicateurs de focus masqués, les interactions uniquement par glisser-déposer, les petites zones tactiles, le placement incohérent de l’aide et les parcours d’authentification inaccessibles.

Ces mises à jour améliorent l’accessibilité sur les sites web, applications mobiles, documents en ligne et autres contenus numériques, tout en restant alignées sur les quatre principes des WCAG : le contenu doit être perceptible, utilisable, compréhensible et robuste. 

Il est également important de noter que WCAG 2.2 ne remplace pas les versions précédentes des directives. Tous les critères de succès de WCAG 2.1 (et WCAG 2.0) restent inchangés et pleinement applicables, WCAG 2.2 venant simplement s’ajouter à cette base.

Nouveaux critères de succès WCAG 2.2 expliqués

Avec une meilleure compréhension des différences entre WCAG 2.2 et les versions précédentes, examinons les nouveaux critères de WCAG 2.2(opens in a new tab).

2.4.11 Focus non masqué (minimum)

Ce critère(opens in a new tab) garantit qu’un indicateur visuel de focus clavier (comme une bordure ou une surbrillance) est partiellement visible pour les utilisateurs. Ajouter un indicateur de focus permet aux utilisateurs de localiser et d’interagir avec le composant ciblé, comme des boutons ou des liens. 

Lors de la conception avec des en-têtes fixes, des éléments collants ou des modales, assurez-vous que le focus clavier ne passe pas derrière une interface masquante. Les développeurs peuvent utiliser JavaScript pour faire défiler les éléments dans la vue avec ‘.scrollIntoView({block:”nearest”})’ ou des méthodes similaires. Le CSS doit également éviter les mises en page fixes qui recouvrent les éléments interactifs sans repositionnement dynamique. 

2.4.12 Focus non masqué (amélioré)

En s’appuyant sur l’exigence minimale, le critère amélioré(opens in a new tab) exige des indicateurs visuels de focus encore plus robustes. Il requiert que l’élément en focus soit entièrement visible, sans être masqué de quelque manière que ce soit. Cela encourage les concepteurs à utiliser des éléments qui se démarquent nettement, améliorant ainsi la visibilité et la clarté des éléments ciblés. 

Pour répondre à cette exigence, les développeurs doivent créer des interfaces qui font toujours défiler l’élément ciblé entièrement dans la vue. Évitez la visibilité partielle ou le chevauchement des composants d’interface. Utilisez JavaScript comme ‘.scrollIntoView({block:”center”})’ ou implémentez une logique de défilement personnalisée garantissant une cible en focus totalement visible sur toutes les tailles et orientations d’écran.

2.4.13 Apparence du focus

Le critère 2.4.13(opens in a new tab) exige que l’indicateur visible pour tout composant d’interface utilisateur respecte des exigences minimales de taille et de contraste. Les indicateurs doivent être au moins aussi grands qu’une bordure de 2 pixels autour du composant et doivent contraster avec les couleurs adjacentes à un ratio de 3:1. 

Lors de la création d’indicateurs de focus, utilisez des styles de focus visibles qui ne reposent pas uniquement sur des contours subtils ou des ombres portées. Par exemple, un contour solide de 2 pixels avec un contraste de couleur suffisant ou une surbrillance d’arrière-plan satisfait aux normes de conformité. De plus, évitez de supprimer les contours d’indicateur de focus via ‘outline: none’ sauf si une alternative plus accessible est appliquée. 

2.5.7 Mouvements de glissement

Le critère 2.5.7(opens in a new tab) exige que les actions de glissement effectuées par les utilisateurs soient rendues accessibles. Par exemple, lorsqu’un utilisateur fait glisser un élément pour le réorganiser ou interagit avec un curseur, des méthodes alternatives (comme des boutons) doivent être disponibles pour ceux qui ne peuvent pas effectuer l’action. 

Les développeurs doivent s’assurer que ces mouvements prennent en charge des méthodes d’entrée alternatives comme l’interaction au clavier (par exemple, flèches ou boutons pour déplacer des éléments) ou la saisie au clavier. Par exemple, les utilisateurs peuvent cliquer sur des flèches pour déplacer un élément de liste vers le haut ou le bas au lieu d’exiger un glisser-déposer. Cela soutient les utilisateurs ayant une motricité limitée qui peuvent avoir des difficultés avec des mouvements précis du pointeur. 

2.5.8 Taille de la cible (minimum)

Les éléments interactifs, tels que les boutons et les liens, doivent avoir une taille de cible minimale(opens in a new tab) afin de garantir qu’ils puissent être facilement touchés ou cliqués. Des cibles plus grandes réduisent le risque d’erreur et améliorent l’expérience des utilisateurs de technologies d’assistance. Le critère de succès recommande que les cibles interactives mesurent au moins 24 par 24 pixels CSS, sauf s’il y a un espacement suffisant autour d’elles ou si des exceptions spécifiques s’appliquent. 

Pour répondre à cette exigence, assurez-vous que les cibles tactiles et cliquables respectent la taille minimale soit directement, soit via du padding. Si les cibles sont plus petites, assurez un espacement minimum de 24 pixels entre elles pour réduire les activations accidentelles. Utilisez les media queries et le CSS pour adapter la taille des cibles sur mobile et interfaces tactiles sans perturber la mise en page. 

3.2.6 Aide cohérente

L’aide cohérente(opens in a new tab) fait référence à la nécessité que les fonctionnalités d’assistance et de guidage, comme les mécanismes d’aide ou les FAQ, apparaissent à des emplacements prévisibles sur votre site (sauf si l’utilisateur en décide autrement). Cette cohérence aide les utilisateurs à trouver rapidement les options d’aide et à naviguer plus facilement sur votre site — ce qui bénéficie particulièrement aux personnes ayant des troubles cognitifs. 

Pour être conforme, assurez-vous que les mécanismes d’aide comme les boutons de chat en direct, les liens de contact support ou l’accès à la FAQ sont placés de manière cohérente sur toutes les pages concernées — visuellement et de façon programmatique. L’ordre et l’emplacement doivent rester fixes dans les zones de navigation, sauf si l’utilisateur les personnalise ou les réorganise. La cohérence dans l’étiquetage et le positionnement permet aux utilisateurs, notamment ceux ayant des troubles cognitifs, d’anticiper où trouver de l’aide. 

3.3.7 Saisie redondante

Si les utilisateurs doivent saisir des informations dans plusieurs champs, le critère de succès 3.3.7(opens in a new tab) exige plusieurs mécanismes pour minimiser la redondance. Par exemple, les informations déjà saisies par l’utilisateur ne devraient pas avoir à être ressaisies lors de la même session, sauf si cela est essentiel pour la sécurité, si la ressaisie est initiée par l’utilisateur ou si l’information n’est plus valide. 

Pour se conformer, des techniques telles que le stockage de session ou la mémoire côté client doivent être mises en œuvre pour préserver les saisies de l’utilisateur tout au long d’un processus en plusieurs étapes. Par exemple, si un utilisateur saisit son adresse sur un écran d’un formulaire de commande, les mêmes données doivent être automatiquement reprises sur les écrans suivants si nécessaire. Cela réduit les répétitions inutiles, ce qui peut être particulièrement contraignant pour les personnes ayant des troubles de la mémoire ou de la motricité.

3.3.8 Authentification accessible (minimum)

Les normes d’authentification accessible(opens in a new tab) exigent que toute forme d’authentification utilisateur (comme les champs de connexion) soit conçue pour s’adapter aux personnes en situation de handicap. Cela peut inclure la fourniture d’options pour différents modes de saisie, des messages d’erreur clairs, des processus d’authentification et une assistance pour la récupération de mot de passe, afin de garantir que les utilisateurs puissent accéder à leur compte sans obstacle. 

Pour répondre à cette exigence, il faut créer des méthodes d’authentification qui réduisent la charge cognitive, comme autoriser le copier-coller dans les champs de mot de passe, intégrer des gestionnaires de mots de passe et proposer des options de connexion sans mot de passe (ex. : codes à usage unique envoyés par e-mail). Si un CAPTCHA est utilisé, assurez-vous qu’une méthode de vérification alternative est disponible et ne nécessite pas de résoudre un défi basé sur la mémoire, la reconnaissance de motifs ou l’interprétation. 

3.3.9 Authentification accessible (améliorée)

La norme d’authentification accessible améliorée(opens in a new tab) va plus loin en exigeant aucun test de fonction cognitive à aucune étape de l’authentification, sauf si un mécanisme est disponible qui ne nécessite pas de compétences cognitives. 

Pour répondre pleinement à cette exigence, éliminez la dépendance aux mots de passe traditionnels et aux questions de sécurité lorsque cela est possible. Proposez plutôt des alternatives telles que la connexion biométrique, des liens d’authentification sécurisés envoyés par e-mail ou SMS, ou la reconnaissance d’appareils de confiance. Cela garantit que les personnes ayant des troubles cognitifs peuvent s’authentifier de manière autonome sans la barrière du rappel ou du déchiffrage d’informations.

Balance de la justice tenant les icônes WCAG 2.2 et WCAG 2.1

Quelle version de WCAG devez-vous suivre ?

Au moment de la rédaction de cet article, les organisations doivent se conformer aux normes du niveau AA de WCAG 2.2 pour être en conformité avec des lois telles que l’Americans with Disabilities Act(opens in a new tab) (ADA), la Section 508 ou la Loi sur l’accessibilité pour les personnes handicapées de l’Ontario(opens in a new tab) (AODA). Ces directives traitent de nombreux obstacles majeurs à l’accessibilité, notamment :

• Absence de texte alternatif (ou alt text) sur les images ou autres contenus non textuels, ce qui impacte les personnes malvoyantes ou aveugles. 

• Absence de sous-titres vidéo, de descriptions audio ou de transcriptions, ce qui peut impacter les personnes ayant des handicaps auditifs, des troubles d’apprentissage ou des troubles neurocognitifs. 

• Absence de titres, sous-titres et balises title, ce qui peut compliquer la navigation pour les utilisateurs de lecteurs d’écran. 

• Les “pièges clavier”, qui peuvent rendre le contenu inutilisable pour les personnes qui ne naviguent pas à la souris.

Respecter les normes WCAG 2.2 vous permet de rester conforme aux principales lois sur l’accessibilité et de vous préparer aux futures versions des WCAG, y compris WCAG 3.0. 

Première étape vers la conformité WCAG : testez votre contenu

À mesure que les normes d’accessibilité évoluent, agir tôt permet de réduire les risques et d’offrir de meilleures expériences à tous. Suivre les conseils ci-dessus vous place dans une excellente position pour répondre aux exigences de WCAG 2.2. 

AudioEye simplifie la suite. Notre plateforme d’accessibilité combine intelligemment des tests automatisés avec des audits d’experts pour détecter et corriger les problèmes d’accessibilité, vous aidant à créer une expérience en ligne plus accessible et conforme. Le processus commence avec notre Vérificateur d’accessibilité web gratuit qui vérifie 32 violations WCAG (plus que tout autre outil du marché). Ces problèmes sont automatiquement corrigés via nos corrections automatisées, simplifiant votre chemin vers une expérience plus accessible.

Prêt à passer à l’étape suivante ? Scannez votre contenu maintenant ou planifiez une démo pour découvrir comment AudioEye accélère et facilite la conformité WCAG.