Quoi de neuf dans WCAG 2.2 : Explication des 9 nouveaux critères de succès

Les normes d’accessibilité du Web n’évoluent pas au ralenti. À mesure que les habitudes de navigation se tournent vers le mobile, que de plus en plus de personnes dépendent du clavier et de la navigation vocale, et que les lacunes des anciennes directives deviennent plus évidentes, les règles pour créer des sites accessibles sont mises à jour pour suivre le rythme. La plus récente de ces mises à jour est WCAG 2.2(opens in a new tab).

Une distinction importante à faire : WCAG 2.2 ne remplace pas WCAG 2.0 ou 2.1 — les trois restent des normes actives. Mais le World Wide Web Consortium (W3C) recommande de viser la version la plus récente, car elle s’appuie sur tout ce qui précède.

Pour la plupart des organisations, la question est plutôt « qu’est-ce qui a changé dans WCAG 2.2, et que dois-je faire ? » que « qu’est-ce que WCAG 2.2 ». Si vous êtes déjà conforme à WCAG 2.1 niveau AA, vous avez déjà fait la majeure partie du chemin : WCAG 2.2 ajoute neuf nouveaux critères de succès et en retire un, donc l’écart est faible, mais précis.

Ci-dessous, nous détaillons les neuf nouveaux critères, expliquons ce qui a changé par rapport à WCAG 2.1, et montrons comment vérifier où votre site présente des lacunes.

L’évolution des Règles pour l’accessibilité des contenus Web

WCAG a évolué régulièrement depuis la première publication du W3C en 1999. WCAG 2.0 (créé en 2008) a introduit les quatre principes de l’accessibilité du Web et a étendu les directives à tout contenu numérique ; WCAG 2.1 (créé en 2018) a ajouté des critères pour le mobile et un plus large éventail de handicaps ; et WCAG 2.2, publié en octobre 2023, ajoute les neuf nouveaux critères de succès détaillés ci-dessous, axés sur les utilisateurs ayant une basse vision, des troubles cognitifs ou d’apprentissage, et des capacités motrices limitées.

WCAG 2.2 : Quoi de neuf et pourquoi c’est important

Les neuf ajouts se répartissent en trois niveaux de conformité : A, AA et AAA, qui indiquent jusqu’où un site doit aller pour être conforme, la plupart des objectifs légaux et organisationnels visant le niveau AA. Le tableau ci-dessous détaille chaque nouveau critère : ce qu’il exige, à qui il profite et pourquoi il est important en pratique.

WCAG 2.4.11 : Focus non masqué (minimum) (Niveau AA)

WCAG 2.4.11(opens in a new tab) exige que, lorsqu’un élément reçoit le focus clavier, au moins une partie de celui-ci reste visible et ne soit pas complètement masquée par d’autres contenus, comme des en-têtes fixes ou des pop-ups. Pour les utilisateurs voyants qui naviguent au clavier, connaître l’emplacement du focus est essentiel pour se déplacer sur les pages. Cependant, il arrive que des éléments focalisés soient masqués par d’autres éléments du site.

Ajouter un élément de focus visible peut améliorer la navigation pour les personnes ayant des troubles cognitifs ou visuels ; plus l’indicateur de focus est visible, plus il est facile à suivre lors de la navigation sur les pages Web.

WCAG 2.4.12 : Focus non masqué (amélioré) (Niveau AAA)

WCAG 2.4.12(opens in a new tab) va plus loin que 2.4.11, exigeant qu’un élément focalisé au clavier soit entièrement visible, sans qu’aucune partie ne soit masquée par d’autres contenus de la page. Cela garantit que l’élément focalisé est totalement visible pour l’utilisateur, ce qui améliore la navigation pour les personnes ayant une vision limitée ou basse. Les personnes ayant des limitations d’attention (comme des troubles de la mémoire à court terme) peuvent également se concentrer plus facilement lorsque tout le focus est visible.

WCAG 2.4.13 : Apparence du focus (Niveau AAA)

WCAG 2.4.13(opens in a new tab) exige que les indicateurs de focus soient suffisamment grands et présentent un contraste de couleurs d’au moins 3:1 entre les états focalisé et non focalisé, afin que les utilisateurs puissent clairement voir quel élément est en focus. Par exemple, lorsqu’un lien reçoit le focus, un contour apparaît autour de lui. La couleur de ce contour doit avoir un contraste suffisant avec la couleur de fond de la page.

S’assurer que les indicateurs de focus ont un contraste de couleur suffisant permet aux utilisateurs de voir facilement les petits changements d’apparence visuelle. Cela est particulièrement bénéfique pour les personnes âgées ou les utilisateurs clavier, car ils peuvent facilement suivre leur position sur une page lors de la navigation.

WCAG 2.5.7 : Mouvements de glisser-déposer (Niveau AA)

WCAG 2.5.7(opens in a new tab) exige que toute action réalisée par glisser-déposer dispose également d’une alternative à un seul pointeur, comme un tapotement ou un bouton à l’écran, sauf si le glisser-déposer est essentiel. Par exemple, un site peut permettre d’utiliser le clavier avec les flèches directionnelles ou fournir des boutons à l’écran pour déplacer un curseur ou trier une liste. Cela garantit que les personnes qui ont des difficultés ou ne peuvent pas effectuer de mouvements de glisser-déposer peuvent tout de même utiliser l’interface drag-and-drop.

WCAG 2.5.8 : Taille de la cible (minimum) (Niveau AA)

WCAG 2.5.8(opens in a new tab) exige que les cibles cliquables mesurent au moins 24x24 pixels CSS, ou disposent d’un espacement suffisant pour éviter les activations accidentelles. Lorsque les boutons et autres éléments cliquables sont petits, il est difficile pour les personnes ayant des tremblements ou des troubles moteurs fins de les activer sans cliquer accidentellement sur un autre élément.

Cette nouvelle exigence permet aux personnes ayant des limitations motrices fines de cliquer facilement sur les boutons. Elle améliore également l’expérience mobile, car les utilisateurs disposent d’un espacement suffisant pour sélectionner de petits boutons.

WCAG 3.2.6 : Aide cohérente (Niveau A)

WCAG 3.2.6(opens in a new tab) exige que les mécanismes d’aide, comme les coordonnées ou une option de chat, apparaissent dans le même ordre relatif sur chaque page où ils sont proposés. Par exemple, si un site propose une option « Chat », elle doit apparaître dans le coin inférieur droit de chaque page. Ou bien les coordonnées, y compris le numéro de téléphone, les horaires ou l’adresse e-mail, sont listées dans le pied de page de chaque page.

En listant systématiquement les informations utiles au même endroit, les personnes qui ont des difficultés à localiser l’aide ou à se souvenir de l’emplacement des informations peuvent les retrouver plus facilement.

WCAG 3.3.7 : Saisie redondante (Niveau A)

WCAG 3.3.7(opens in a new tab) exige que les informations qu’un utilisateur a déjà saisies dans un processus soient automatiquement renseignées ou disponibles à la sélection, plutôt que d’être demandées à nouveau. Cela évite aux utilisateurs de saisir plusieurs fois les mêmes informations, réduit le risque d’erreurs et limite la saisie de texte.

WCAG 3.3.8 : Authentification accessible (minimum) (Niveau AA)

WCAG 3.3.8(opens in a new tab) exige que les connexions ne dépendent pas d’un test de fonction cognitive(opens in a new tab) (comme mémoriser un mot de passe ou résoudre une énigme), sauf si une méthode alternative ou une assistance est disponible. Cela simplifie l’authentification pour les personnes ayant des troubles cognitifs et leur permet de s’authentifier selon leurs besoins. Un mécanisme utile est l’utilisation de gestionnaires de mots de passe, qui réduisent les besoins de mémoire et la saisie répétée d’informations.

WCAG 3.3.9 : Authentification accessible (améliorée) (Niveau AAA)

WCAG 3.3.9(opens in a new tab) applique la même règle que 3.3.8 mais de façon plus stricte, interdisant la reconnaissance d’objets ou le contenu fourni par l’utilisateur (comme une image téléchargée) comme méthode d’authentification. Cela garantit que les personnes ayant des troubles cognitifs liés à la mémoire, à la lecture (dyslexie, par exemple), aux chiffres ou au traitement perceptif peuvent se connecter ou s’authentifier facilement.

Ce qui a été supprimé : 4.1.1 Analyse syntaxique

WCAG 2.2 a supprimé un critère, 4.1.1 Analyse syntaxique, marquant la première fois qu’un critère de succès est retiré des directives. Ce critère exigeait à l’origine un balisage HTML propre et bien formé, mais le W3C a jugé qu’il était obsolète car les navigateurs modernes et les technologies d’assistance gèrent désormais sans problème les erreurs de balisage concernées.

Le fait de le retirer ne signifie pas que la validité du HTML n’a plus d’importance ; un balisage bien structuré reste bénéfique pour l’accessibilité et demeure une bonne pratique. L’effet pratique est limité : si vos tests automatisés signalaient auparavant des erreurs d’analyse comme un échec WCAG, ces échecs ne comptent plus contre la conformité 2.2.

WCAG 2.2 vs. WCAG 2.1 : Qu’est-ce qui a vraiment changé

WCAG 2.2 est un sur-ensemble de WCAG 2.1 : il conserve tous les critères de succès de 2.1 sauf le 4.1.1 Analyse syntaxique retiré, puis en ajoute neuf nouveaux. La conséquence pratique est la suivante : être conforme à WCAG 2.2 signifie aussi être conforme à 2.1, il n’y a donc pas de compromis à viser la version la plus récente. Si vous êtes déjà conforme à WCAG 2.1 niveau AA, l’écart réel se limite aux six nouveaux critères de niveaux A et AA ; les trois ajouts de niveau AAA sont optionnels. En résumé, passer de 2.1 à 2.2 n’est pas une refonte — c’est une courte liste de tâches bien définie.

Checklist WCAG 2.2 (Niveau AA)

Si vous êtes déjà conforme à WCAG 2.1 niveau AA, voici les six nouveaux critères à traiter pour atteindre le niveau AA de WCAG 2.2. Les trois ajouts de niveau AAA (2.4.12, 2.4.13 et 3.3.9) sont optionnels.

• Le focus clavier reste visible (2.4.11) : Parcourez chaque page au clavier et vérifiez que l’élément focalisé n’est jamais totalement masqué par des en-têtes fixes, des bandeaux de cookies ou des pop-ups.

• Le glisser-déposer a une alternative (2.5.7) : Pour toute action de glisser-déposer (curseurs, réorganisation, contrôles de carte), proposez une option à un seul pointeur, comme un tapotement ou des boutons à l’écran.

• Les cibles sont suffisamment grandes (2.5.8) : Vérifiez que les éléments cliquables mesurent au moins 24×24 pixels CSS, ou disposent d’un espacement suffisant pour éviter d’activer accidentellement une cible adjacente.

• L’aide est cohérente (3.2.6) : Placez les mécanismes d’aide (ex. : liens de contact, chat, support, etc.) au même endroit relatif sur chaque page qui les propose.

• Ne demandez pas la même info deux fois (3.3.7) : Renseignez automatiquement ou laissez les utilisateurs réutiliser les informations déjà saisies plus tôt dans le même processus, sauf si la ressaisie est essentielle.

• Les connexions ne reposent pas sur la mémoire ou des énigmes (3.3.8) : Proposez une alternative accessible partout où l’authentification nécessite un test de fonction cognitive, comme se souvenir d’un mot de passe ou résoudre un CAPTCHA.

Plusieurs de ces critères, notamment la visibilité du focus, l’aide cohérente et l’authentification accessible, ne peuvent pas être entièrement vérifiés par des outils automatisés. Un scan d’accessibilité gratuit est un moyen rapide de savoir où en est votre site aujourd’hui.

Comment AudioEye simplifie la conformité WCAG 2.2

WCAG 2.2 a affiné l’accessibilité plutôt que de la réinventer, ajoutant neuf critères ciblés qui comblent de vraies lacunes pour les utilisateurs naviguant au clavier, gérant des connexions ou utilisant des appareils mobiles. Le défi pour la plupart des organisations est de vérifier que leur site y répond effectivement et de le maintenir à jour à mesure que les normes évoluent.

C’est là que la bonne approche compte : plusieurs critères WCAG 2.2, dont la visibilité du focus, l’aide cohérente et l’authentification accessible, ne peuvent pas être confirmés par l’automatisation seule.

La plateforme AudioEye est conçue précisément pour cette combinaison. AudioEye aide les organisations à atteindre le niveau AA de WCAG 2.2 en associant des corrections automatisées à grande échelle à des experts certifiés et à des tests avec la communauté handicapée pour vérifier les critères que l’automatisation ne peut pas confirmer seule. Et avec le suivi continu, votre site est contrôlé à chaque changement, et les problèmes sont corrigés plus rapidement, suivant l’évolution de WCAG plutôt que de rester figé à l’état actuel.

Prêt à voir où en est votre site par rapport à WCAG 2.2 ? Utilisez le vérificateur d’accessibilité Web gratuit pour le découvrir. Ou planifiez une démo, et nous vous montrerons comment AudioEye vous aide à respecter les normes d’accessibilité et à les maintenir dans le temps.