Ce que signifie WCAG 2.2 pour votre site web

Après deux ans de collecte de retours, le World Wide Web Consortium (W3C) a publié les Web Content Accessibility Guidelines (WCAG) 2.2(opens in a new tab) en tant que recommandation officielle — établissant un nouvel ensemble de critères à prendre en compte pour les entreprises souhaitant rester conformes à des lois telles que l’Americans with Disabilities Act (ADA).

Notamment, les entreprises qui étaient conformes aux normes WCAG 2.1 Niveau AA peuvent ne plus l’être avec WCAG 2.2 — et il est probable que ces exigences évolueront encore dans les prochaines années. Cela signifie que des tests supplémentaires et des analyses d’experts certifiés en accessibilité sont nécessaires pour garantir la conformité des entreprises.

Ci-dessous, nous proposons un aperçu des nouveaux critères et des conseils pour aider les entreprises à identifier les contenus numériques qui ne sont plus conformes. Nous expliquerons également comment AudioEye simplifie ce processus, facilitant la conformité aux normes d’accessibilité en constante évolution.

L’évolution des directives d’accessibilité du contenu web

Initialement établies en 1999, les WCAG 1.0 ont constitué la première étape dans la mise en place de directives d’accessibilité pour le web. Les directives originales étaient principalement axées sur le HTML et comprenaient 14 recommandations.

La version suivante, WCAG 2.0, a été créée en 2008 et a élargi sa portée pour inclure les quatre principes de l’accessibilité web. WCAG 2.0 a été introduit après d’importants changements technologiques et s’appliquait à tous les contenus numériques, y compris les documents et les applications mobiles.

WCAG 2.1 a été publié en juin 2018 et s’appuie sur les principes de WCAG 2.0. Cette mise à jour était bienvenue, car WCAG 2.0 ne tenait plus compte des avancées récentes en matière de technologie et d’utilisation du web. Les nouvelles directives incluent plusieurs nouveaux critères de succès pour améliorer l’accessibilité web sur les appareils mobiles.

Cela nous amène à octobre 2023, date de publication de la dernière version des WCAG. Les directives incluent neuf nouveaux critères de succès qui visent spécifiquement à offrir plus de soutien aux personnes ayant une basse vision, des troubles cognitifs ou d’apprentissage, et des capacités motrices limitées.

Parce que les WCAG sont considérées comme la référence en matière d’accessibilité des sites web, la Section 508 du Rehabilitation Act exige que les agences fédérales respectent les WCAG 2.0 A/AA. Pour les entreprises privées, le Department of Justice (DOJ) a indiqué que pour se conformer à l’ Americans with Disabilities Act (ADA)(opens in a new tab) , les organisations doivent se conformer aux recommandations WCAG.

Un graphique montrant les trois niveaux de conformité WCAG : Niveau A, Niveau AA et Niveau AAA.

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

Comme mentionné ci-dessus, WCAG 2.2 comprend neuf nouveaux critères de succès, qui s’ajoutent aux 78 critères de WCAG 2.1. Chacun de ces critères contribue à améliorer l’accessibilité numérique pour trois grands groupes : les personnes ayant des troubles cognitifs ou d’apprentissage, les personnes malvoyantes et les personnes en situation de handicap utilisant des appareils mobiles.

La dernière version des directives d’accessibilité a également supprimé un ancien critère désormais obsolète : WCAG 4.1.1 : Parsing. C’est la première fois qu’un critère de succès est retiré des directives, ce qui témoigne de leur capacité d’adaptation aux tendances numériques actuelles.

Comme pour les versions précédentes, les nouveaux critères sont répartis en trois niveaux de conformité : A, AA et AAA. Selon l’avis récemment publié par le DOJ concernant l’accessibilité des sites web dans le cadre du Titre II de l’ADA, les entreprises doivent se conformer aux normes WCAG 2.X Niveau AA.

Dans cette optique, examinons les nouveaux critères et comment chacun contribue à résoudre les problèmes d’accessibilité.

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

Pour les utilisateurs voyants qui naviguent au clavier, connaître le point de focus actuel est essentiel pour parcourir les pages. Cependant, les éléments en focus peuvent parfois être masqués par des en-têtes fixes, des pop-ups ou d’autres contenus qui apparaissent à l’écran.

Lorsqu’un composant d’interface utilisateur reçoit le focus clavier, WCAG 2.4.11(opens in a new tab) stipule qu’une partie de celui-ci doit rester visible et ne pas être masquée par d’autres contenus à l’écran. Cela peut améliorer la navigation et le focus pour les personnes ayant des troubles cognitifs ou visuels ; toutefois, plus l’indicateur de focus est visible, plus il est facile pour les utilisateurs de suivre leur 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) suit les mêmes directives que le critère précédent ; cependant, la différence clé ici est qu’aucune partie de l’indicateur de focus ne peut être cachée par d’autres contenus de la page. Cela garantit que l’élément en focus est entièrement visible pour l’utilisateur, ce qui améliore la navigation pour les personnes malvoyantes ou ayant une vision limitée. Les utilisateurs ayant des limitations d’attention (comme des troubles de la mémoire à court terme) peuvent également se concentrer plus facilement lorsque le focus est entièrement visible.

WCAG 2.4.13 : Apparence du focus (Niveau AAA)

Les indicateurs de focus mettent en évidence l’élément d’une page web actuellement en focus. WCAG 2.4.13(opens in a new tab) exige que les indicateurs de focus aient un contraste de couleur suffisant (au moins 3:1 entre les mêmes pixels dans les états focus et non focus) et soient suffisamment grands pour être clairement visibles. Par exemple, lorsqu’un lien reçoit le focus, un contour s’affiche autour du lien. La couleur de ce contour doit présenter un contraste suffisant avec la couleur de fond de la page.

S’assurer que les indicateurs de focus ont un contraste suffisant permet aux utilisateurs de percevoir facilement les petits changements d’apparence visuelle. Cela est particulièrement bénéfique pour les personnes âgées ou les utilisateurs de 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)

Le glisser-déposer peut être fastidieux et source d’erreurs pour de nombreuses personnes, qu’elles utilisent un clavier, aient une déficience motrice ou dépendent de dispositifs d’entrée adaptés comme des pointeurs de tête ou des émulateurs de souris contrôlés par la voix.

WCAG 2.5.7(opens in a new tab) exige que les mouvements de glisser-déposer ne soient pas le seul moyen d’effectuer des actions essentielles sur une page, que ce soit pour manipuler un curseur ou réorganiser des composants dans une interface de glisser-déposer.

Par exemple, un site web pourrait permettre l’utilisation du clavier avec les flèches haut/bas/gauche/droite ou proposer des boutons à l’écran que l’utilisateur peut cliquer pour déplacer un curseur ou trier une liste. Cela garantit que les personnes ayant des difficultés ou étant incapables d’effectuer des mouvements de glisser-déposer peuvent tout de même utiliser l’interface.

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

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 activer accidentellement un autre élément.

WCAG 2.5.8(opens in a new tab) exige que la taille minimale de tous les éléments cliquables (comme les boutons d’appel à l’action) soit d’au moins 24 x 24 pixels CSS. Il exige également que les sites web prévoient au moins 24 pixels CSS d’espacement entre les cibles adjacentes.

Ce critère constitue une alternative Niveau AA à WCAG 2.5.5 : Taille de la cible(opens in a new tab), une exigence de Niveau AAA introduite dans WCAG 2.1 et qui impose une taille de cible d’au moins 44 x 44 pixels CSS pour tous les éléments cliquables.

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 des boutons plus petits.

WCAG 3.2.6 : Aide cohérente (Niveau A)

Si des fonctionnalités ou mécanismes d’aide — comme les coordonnées de contact d’un site ou un chatbot d’auto-assistance — sont disponibles sur plusieurs pages d’un site, WCAG 3.2.6(opens in a new tab) exige qu’ils apparaissent au même endroit relatif et dans le même ordre sur chaque page où ils sont présents.

Par exemple, si un site propose une option ‘Chat’, celle-ci doit apparaître dans le coin inférieur droit de chaque page. Ou bien les coordonnées de contact, comme un numéro de téléphone, les horaires d’ouverture ou une adresse e-mail, doivent être indiquées dans le pied de page de chaque page.

En affichant systématiquement les informations utiles au même endroit, les personnes ayant 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)

Certains formulaires demandent aux utilisateurs de saisir plusieurs fois les mêmes informations, ce qui peut être pénible pour les personnes ayant des troubles moteurs. Cela peut aussi être difficile pour les personnes ayant des troubles cognitifs, car elles peuvent avoir du mal à se souvenir des informations déjà saisies.

WCAG 3.3.7(opens in a new tab) exige que les sites web remplissent automatiquement les champs ou permettent aux utilisateurs de réutiliser les données déjà saisies. Cela évite aux utilisateurs de devoir saisir plusieurs fois les mêmes informations, réduit le risque d’erreurs et diminue la nécessité de saisir du texte.

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

L’objectif de WCAG 3.3.8(opens in a new tab) est d’offrir aux personnes ayant des troubles cognitifs un moyen simple et accessible de se connecter à des sites web et applications mobiles. Si un test de fonction cognitive(opens in a new tab) — comme mémoriser un mot de passe ou identifier des images ou des caractères — est utilisé, les sites doivent proposer au moins une autre méthode d’authentification.

Cela simplifie le processus d’authentification pour les personnes ayant des troubles cognitifs et leur permet de s’authentifier selon leurs besoins individuels. Un mécanisme pouvant aider est l’utilisation de gestionnaires de mots de passe, qui réduisent les besoins de mémoire et la charge de ressaisie des informations.

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

Similaire au critère précédent, WCAG 3.3.9(opens in a new tab) vise à simplifier le processus de connexion pour les personnes ayant des troubles cognitifs. Cependant, ce critère va plus loin et n’autorise pas l’authentification par reconnaissance d’objets ou par contenu fourni par l’utilisateur, comme une image téléchargée. Cela garantit que les personnes ayant des difficultés cognitives liées à la mémoire, à la lecture (dyslexie, par exemple), aux chiffres ou au traitement perceptif peuvent se connecter ou s’authentifier facilement.

Les WCAG sont-elles une obligation légale ?

Il est à noter que plusieurs nouveaux critères de succès de WCAG 2.2 nécessitent des tests manuels pour être identifiés de manière fiable — ce qui souligne la nécessité pour les entreprises de compléter les tests automatisés par des audits manuels réalisés par des experts certifiés en accessibilité et des utilisateurs de technologies d’assistance.

Chez AudioEye, nous collaborons avec plus de 80 membres de la communauté en situation de handicap (appelée AudioEye A11iance) pour auditer de façon experte les sites clients pour les problèmes WCAG. En préparation de la publication de WCAG 2.2, nos testeurs se sont formés aux derniers critères et stratégies de remédiation WCAG.

Vous souhaitez savoir où votre entreprise pourrait ne pas être conforme aux dernières normes WCAG ? Planifiez une consultation gratuite pour discuter de l’accessibilité de votre site web et découvrir comment AudioEye peut vous aider à identifier et corriger les problèmes d’accessibilité à la source.

Étapes pour garantir la conformité de votre site aux normes WCAG 2.2

Même si votre organisation doit respecter les normes WCAG 2.0 ou 2.1, il est recommandé de se conformer aux nouvelles normes WCAG. Cela améliore l’accessibilité de votre site et démontre votre engagement à offrir une expérience accessible et inclusive.

Voici trois façons de mettre en œuvre les normes WCAG 2.2 sur votre site.

Réalisez un audit d’accessibilité

La première étape pour intégrer les critères WCAG 2.2 est d’auditer votre système actuel. Cela permettra d’identifier les problèmes d’accessibilité existants et de vous donner un point de départ pour la mise en œuvre de WCAG 2.2. Un Vérificateur d’accessibilité comme AudioEye peut vous y aider.

Mettez en œuvre les changements selon les résultats de l’audit

Une fois les résultats de l’audit obtenus, commencez à mettre en œuvre les changements. Nous recommandons de débuter par les problèmes mineurs — comme la correction de liens brisés ou l’ajout de textes alternatifs aux images — avant de s’attaquer aux problèmes plus importants.

Faites appel à des experts certifiés pour des tests manuels

Les plateformes d’accessibilité automatisées ne peuvent détecter que les problèmes courants. Les problèmes plus complexes, comme un texte alternatif mal rédigé ou une faible compatibilité avec la navigation au clavier ou les technologies d’assistance, nécessitent des tests manuels. Non seulement ces tests permettent de détecter ces problèmes, mais ils peuvent aussi fournir des recommandations pour les corriger.

Par exemple, la plateforme d’accessibilité numérique d’AudioEye utilise des tests automatisés pour détecter les problèmes courants et propose des corrections automatiques. Tout ce qui ne peut être corrigé automatiquement est pris en charge par notre équipe de testeurs humains qui résolvent les problèmes grâce à des corrections personnalisées.

Une approche hybride des tests d’accessibilité améliore l’accessibilité globale de votre site et crée une expérience plus inclusive.

Une page web stylisée avec plusieurs erreurs d’accessibilité signalées par des points d’exclamation, à côté d’un symbole d’accessibilité vert.

Comment AudioEye simplifie la conformité WCAG 2.2

À mesure que les normes WCAG évoluent, les organisations doivent surveiller et tester en continu leurs sites pour détecter les erreurs d’accessibilité ou les violations WCAG. Cela améliore l’accessibilité du site et aide à répondre aux exigences légales.

Chez AudioEye, nous veillons à ce que votre site respecte les dernières normes WCAG grâce à des tests automatisés et des tests experts réalisés par un groupe d’experts en accessibilité. Nous collaborons également avec plus de 80 membres de la communauté en situation de handicap (AudioEye A11iance) pour effectuer des tests personnalisés sur les sites. Chacun de nos testeurs a été formé à la dernière version des normes WCAG pour garantir la conformité aux nouveaux critères de succès.

Le meilleur avec AudioEye ? Vous n’avez pas besoin de suivre les changements vous-même — nous le faisons pour vous ! Nos Audits experts testent régulièrement votre site pour détecter et corriger les problèmes d’accessibilité avant qu’ils n’impactent vos clients.

Prêt à voir à quel point votre site est conforme aux normes WCAG 2.2 ? Planifiez une démo gratuite avec AudioEye et découvrez comment nous pouvons simplifier votre parcours vers l’accessibilité.