Aller le contenu

WCAG 2.2 : La nouvelle mise à jour arrive à grand pas

Le WCAG (Web Content Accessibility Guidelines), est une ligne directrice comportant plusieurs règles d’accessibilité numérique. Ceux-ci présentent une multitude de recommandations afin de rendre les sites Web plus accessibles. Le W3C (World Wide Web Consortium), un organisme de normalisation international, définissent ces règles. Elles permettent d’obtenir un accès intégral aux contenus présents sur le Web pour tous les utilisateurs, incluant ceux qui ont des handicaps visuels, auditifs, de compréhension, de la parole ou encore de dextérité. La mise à jour 2.2 de WCAG comprend de nouvelles règles qui viennent renforcer les stratégies d’accessibilité web que l’on retrouvait dans la version 2.1. Les améliorations touchent principalement le soutien aux personnes avec des troubles cognitifs et d’apprentissage, aux utilisateurs malvoyants et aux utilisateurs handicapés qui se servent des appareils mobiles.

WCAG 2.2

Une meilleure navigation pour les personnes avec des difficultés

Avec l’arrivée de la version 2.2 du WCAG, on y retrouve de nouvelles règles qui aident les développeurs de sites Web à s’assurer d’une plus grande accessibilité. L’une de ces règles à appliquer par les développeurs Web permet à la fois aux utilisateurs de savoir où ils se trouvent sur une page Web grâce à un indicateur de mise au point qui se détache de l’arrière-plan. De ce fait, un utilisateur qui a une faible sensibilité au contraste peut désormais facilement voir où se trouve le focus du clavier lorsqu’il navigue sur une page Web. Grâce à un contour noir autour d’un bouton qui le différencie de ses pairs, il arrive à discerner où est le focus du clavier sur une page et peut ainsi cliquer sur le bouton de son choix sans faire d’erreur.

La couleur au sein du focus

Dans le même ordre d’idées, les développeurs Web doivent respecter plusieurs critères pour que leurs sites Web se conforment aux recommandations en ce qui a trait à la nouvelle norme d’accessibilité. Entre autres, lorsque le focus du clavier est dirigé sur un bouton en particulier, le ratio du contraste doit être changé au minimum à 4.5:1. 

Voici quelques exemples de ratio de contraste qui sont à 4.5:1

  • Gris (#767676) sur blanc
  • Mauve (#CC21CC) sur blanc
  • Bleu (#000063) sur gris (#808080)
  • Rouge (#E60000) sur jaune (#FFFF47)

Également, aucune partie de l’indicateur ne doit être masquée par du contenu autre que ce qui est choisi par le focus du clavier. Ceci est bénéfique pour toutes les personnes qui utilisent exclusivement le clavier, les personnes malvoyantes et celles qui sont aux prises avec des limitations d’attention, des limitations de mémoire ou des limitations dans les processus exécutifs.

Une utilité pour les étudiants grâce au WCAG 2.2

Cette nouvelle mise à jour peut être bénéfique pour les étudiants atteints de dyslexie ou qui ont des troubles cognitifs. Les points de référence fixes permettent de facilement retrouver le bon contenu en fonction des localisateurs de page qui se trouvent dans l’affichage par défaut ou sur la version imprimée d’un texte. En d’autres mots, les publications électroniques, qui incluent la navigation vers les références de numéro de page qui correspondent à la version papier de la publication, peuvent être autant bien interprétées par l’enseignant que par l’étudiant qui a décidé d’agrandir la taille des mots pour mieux les lire.

De meilleures modalités d’entrée avec le clavier

Faites place au dragging

Avec la nouvelle mise à jour, il sera maintenant plus facile d’utiliser des fonctionnalités via diverses entrées au-delà du clavier grâce au dragging. Certains utilisateurs ne peuvent pas effectuer de mouvements de traînée de manière précise, tels que le glisser-déposer (drag & drop). Bien que cette méthode soit assez simple pour les utilisateurs qui ont une souris, elle peut être beaucoup plus compliquée pour d’autres. Les utilisateurs qui ont du mal à effectuer des gestes basés sur le chemin, comme une personne aux prises avec des tremblements dans les mains, peuvent toujours utiliser une interface de pointeur. Une méthode alternative sera fournie lors de l’arrivée de la mise à jour pour que les utilisateurs à mobilité réduite puissent utiliser cette fonctionnalité avec un pointeur (souris, stylet ou contact tactile). Les développeurs Web devront désormais fournir un autre moyen de faire glisser un élément, par exemple en tapant ou en cliquant.

Les boutons ne seront plus trop petits

Est-ce que ça vous est déjà arrivé de cliquer sur un autre bouton que celui désiré sur une page Web (comme sur un commerce en ligne) et de devoir tout recommencer depuis le début? C’est un problème embêtant, mais ce l’est encore plus pour ceux et celles qui ont des problèmes de motricité. En effet, il peut facilement arriver qu’à cause des mouvements involontaires de leur main, ils cliquent sur le mauvais bouton. C’est pour cela qu’avec l’arrivée du WCAG 2.2, l’une des recommandations est l’élargissement et l’espacement des boutons. Les développeurs Web doivent s’assurer que toutes les cibles interactives soient de taille inférieure à 44 x 44 px et devront être incluses dans une zone d’une largeur et d’une hauteur d’au moins 44 px chacune (par exemple, avec l’ajout d’un espace blanc autour de la cible), afin d’éviter ce genre d’erreurs.

Les pages Web sont maintenant plus prévisibles

Il est déjà arrivé à tout le monde de se retrouver sur un site Web sans savoir où aller, ni quoi faire exactement. Avec la nouvelle mise à jour, il est désormais important que toutes les pages Web puissent apparaître et fonctionner de manière prévisible. L’objectif de la nouvelle mise à jour est de garantir que les utilisateurs puissent trouver de l’aide sans difficulté pour effectuer des tâches sur un site Web. Parfois, même si la tâche ne semble pas être compliquée pour certains, d’autres peuvent éprouver de la difficulté. Ils peuvent aussi décider d’abandonner en cours de route, puisqu’ils n’arrivent pas à trouver l’aide requise. Dans le cas d’un formulaire à remplir, bien que des utilisateurs puissent demander l’aide d’une personne près d’eux, ils auraient préféré accomplir correctement la tâche sans avoir nécessairement à transmettre des informations privées à autrui.

Des mécanismes à inclure pour permettre une meilleure accessibilité

Pour que les développeurs Web puissent respecter les recommandations du WCAG 2.2, chaque site devra inclure au moins l’un des mécanismes suivants afin que les utilisateurs obtiennent l’aide dont ils ont besoin :

1.  Des coordonnées humaines, telles qu’un numéro de téléphone et une adresse courriel, avec les heures d’ouverture.

2.  Un mécanisme de contact humain, tel qu’un système de messagerie, un « tchat » pour parler avec une personne, etc.

3.  Une option d’auto-assistance avec une page contenant une foire aux questions (FAQ), ou encore une page d’assistance.

4.  Un mécanisme de contact entièrement automatisé, tel qu’un « chatbot ».

En d’autres mots, s’il y a la présence d’une option d’aide sur une page Web, les développeurs Web doivent s’assurer qu’elle est disponible de manière cohérente, au même endroit relatif, afin qu’elle puisse être facilement localisée par tout type d’utilisateur.

Contrôles cachés, mais pas pour toujours

Dans tous les sites web, il est préférable que les contrôles nécessaires pour compléter un processus soient visibles au moment où ils sont nécessaires sans que l’utilisateur ait recours au survol du pointeur ou au focus du clavier. En effet, les personnes ayant une faible fonction exécutive, des troubles de la mémoire ou d’autres troubles cognitifs pourraient ne pas être en mesure de trouver les commandes nécessaires pour progresser si elles sont cachées jusqu’à ce que l’accent soit mis sur elles. Elles peuvent également ne pas se souvenir où se trouve les contrôles la prochaine fois qu’elles interagiront avec le site. 

C’est pour ces raisons que les commandes importantes doivent être visibles lorsqu’elles sont nécessaires pour progresser dans un site Web. Par exemple, dans un processus en plusieurs étapes, des contrôles (comme des boutons) peuvent être masqués dans une étape antérieure. Cependant, les boutons requis doivent être constamment visibles au moment où l’utilisateur doit continuer le processus. Les développeurs Web doivent s’assurer que tous les contrôles et les commandes importants demeurent visibles et disponibles tant que ce contrôle est pertinent. À moins qu’ils reçoivent un survol ou un focus, ceux-ci ne devraient pas être cachés.

WCAG 2.2 aide les utilisateurs à corriger les erreurs

Authentification accessible pour tous

Comment permettre aux utilisateurs d’éviter et de corriger les erreurs? La mise à jour WCAG 2.2 recommande deux nouvelles pratiques. En premier lieu, si un processus d’authentification repose sur un test de fonction cognitive, tel que de se rappeler de son nom d’utilisateur et de son mot de passe, il doit y avoir une méthode accessible, facile à utiliser et sécurisée pour se connecter et accéder au contenu. De la simple mémorisation peut être un fardeau très lourd à porter pour les personnes souffrant de certains troubles cognitifs. Les sites Web doivent donc contenir une adresse e-mail et un mot de passe correctement balisés comme authentification de connexion. Bref, s’il existe dans un site un test cognitif pour prouver que l’utilisateur est un humain (par exemple, avec l’utilisation d’un CAPTCHA), les développeurs Web doivent également inclure un autre moyen pour que l’utilisateur s’authentifie sans test cognitif (comme la double authentification).

Remplir automatiquement les informations préalablement entrées

En deuxième lieu, il est préférable que les informations préalablement entrées sur des formulaires soient gardées en mémoire sur le site. Cela garantit aux utilisateurs qu’ils peuvent naviguer avec succès dans les processus en plusieurs étapes et réduit également les efforts cognitifs lorsque des informations sont demandées plus d’une fois. Par ailleurs, on y retrouve aussi une réduction du besoin de se rappeler des informations fournies lors des étapes précédentes. Par exemple, lorsqu’une personne passe une commande sur un site d’achat en ligne, elle entre ses informations une première fois. Ensuite, les informations entrées sur le site sont gardées en mémoire et ne sont plus redemandées par la suite. Les développeurs Web doivent donc s’assurer que lorsqu’un utilisateur remplit un formulaire, toutes les informations saisies précédemment demeurent disponibles via le remplissage automatique. Seule la confirmation des mots de passe et des formulaires abandonnés sont des exceptions.

New Draft: WCAG 2.2

En conclusion, quand arrivera cette mise à jour?

Pour le moment, WCAG 2.2 est encore en version brouillon. La version finale en tant que norme Web « Recommandation W3C » verra le jour en 2021. Au cours des prochains mois, l’Accessibility Guidelines Working Group (AG WG) continuera de recevoir les contributions du public afin de publier une version finale adéquate aux besoins des utilisateurs. Il pourrait y avoir un autre projet de révision si la collaboration du public amène plus de changements que prévu. Mais, la ligne directrice restera la même, c’est-à-dire de donner aux utilisateurs suffisamment de temps pour lire et utiliser le contenu.

Source:

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.