WCAG 2.2 : explication des nouveaux critères proposés

L’appel à commentaires publics est ouvert jusqu’au 4 juin 2021. Vous pouvez faire part de vos commentaires directement sur le dépôt GitHub du groupe de travail WCAG.

9 nouveaux critères d’accessibilité sont proposés à l’ajout pour la version WCAG 2.2.

Parmi eux, on compte 4 critères de niveau simple A, 4 critères de niveau de double A (AA) et un critère de niveau triple A (AAA) :

1. Authentification accessible – A
2. Mouvement de glissement – AA
3. Aide cohérente – A
4. Navigation par saut de page – A
5. Apparence du focus (minimum) – AA
6. Apparence du focus (amélioré) – AAA
7. Contrôles visibles – AA
8. Taille de la zone interactive (minimum) – AA
9. Saisie redondante – A

WCAG 2.2 poursuit l’objectif initié par WCAG 2.1 en élargissant les types de cas utilisateurs pris en compte aux niveaux simple A et double A.

En effet, les nouveaux critères proposés viennent en grande partie prendre en compte les problématiques des personnes avec un handicap cognitif (troubles de la mémoire, atteinte de la capacité à résoudre des problèmes), mais aussi celles des personnes ayant des troubles de la motricité fine et/ou une vision réduite.

Ci-dessous, nous vous présentons ce qui est attendu par chacun de ces nouveaux critères.

---

Authentification accessible — A

D’après la définition en anglais du critère 3.3.7 Accessible Authentication :

« Pour chaque étape d’un processus d’authentification possédant un test qui repose sur une fonction cognitive, il existe au moins une autre méthode d’authentification qui ne repose pas sur une fonction cognitive, ou un mécanisme qui aide l’utilisateur à remplir le test. »

Au cours d’un processus d’authentification ou de connexion, certaines personnes peuvent être gênées si elles se retrouvent face à un test faisant appel à des fonctions cognitives (par exemple au moyen d’un Captcha logique).

En effet, les personnes ayant des troubles de la mémoire seront impactées par un processus d’authentification qui demande la saisie d’un mot de passe, dont elles ne se souviennent pas forcément.

De même, les personnes ayant un ou plusieurs troubles DYS (dyscalculie, dyslexie…) peuvent être bloquées face à un test qui demande de résoudre des opérations mathématiques pour terminer l’authentification, même si le calcul semble « simple » a priori.

Enfin, les personnes avec un trouble cognitif de manière générale seront gênées par tout test qui exige :

• la reconnaissance d’objets précis dans une image, de les compter ou encore les nommer ;
• la résolution d’un puzzle afin de compléter l’authentification.

Il ne s’agit pas d’interdire les tests cognitifs de ce type, mais de proposer une alternative ou de l’aide aux personnes qui ne peuvent pas ou ne savent pas les résoudre.

• Première solution : fournir une alternative qui ne soit pas basée sur un test cognitif. Par exemple : validation d’authentification par email ou par SMS, validation par le biais d’un système d’authentification à 2 facteurs, etc.
• Deuxième solution : fournir une aide à l’utilisateur ou à l’utilisatrice pour remplir le test. Par exemple, pour un formulaire contenant un champ « mot de passe », laisser la possibilité d’utiliser les fonctions de copier-coller, même pour le champ de mot de passe, pour qu’il soit possible de remplir le champ à l’aide d’un gestionnaire de mots de passe.

---

Mouvement de glissement – AA

D’après la définition en anglais du critère 2.5.7 Dragging Movements :

« Toutes les fonctionnalités qui utilisent un mouvement de glissement pour fonctionner peuvent être réalisées par un pointeur avec un contact en un point unique et sans glissement, sauf si le glissement est essentiel. »

Ce critère vise particulièrement les fonctionnalités de type glisser-déposer, ainsi que les potentiomètres.

En effet, les personnes ayant des troubles moteurs et qui ne peuvent pas effectuer de glissement de manière précise peuvent ne pas réussir à terminer une tâche si le mouvement basé sur un glissement est la seule méthode proposée pour la réaliser.

De plus, des personnes qui naviguent avec certaines technologies d’assistance, telle qu’une commande vocale, ne pourront pas réaliser ce type de mouvement.

Contrairement aux gestes complexes (cf. critère 13.10 du RGAA), il est question ici d’actions dont seuls les points de départ et d’arrivée sont pris en compte. La trajectoire n’a pas d’importance, car les points intermédiaires n’ont pas d’influence sur le résultat final.

Prenons un exemple : imaginons une application de gestion de projets dans laquelle il est possible de déplacer un projet d’une colonne « En cours » à une colonne « Terminé » par un geste de glisser-déposer.

Pour que cette fonctionnalité soit accessible, l’interface doit également proposer une méthode alternative qui permette de réaliser le même déplacement sans devoir réaliser une trajectoire.

Par exemple, il serait possible de sélectionner le projet à déplacer en double-cliquant dessus, et de le déplacer dans la colonne « Terminé » en double-cliquant sur cette colonne de destination.

Il serait ainsi possible de déplacer l’élément sans effectuer de mouvement.

---

Aide cohérente — A

D’après la définition en anglais du critère 3.2.6 Consistent Help :

« Pour chaque page d’un ensemble de pages qui fournit un ou plusieurs des moyens suivants pour trouver de l’aide, l’accès à ces moyens est toujours dans le même ordre relatif sur chaque page :

• coordonnées d’une assistance humaine ;
• moyen de contact humain ;
• option d’auto-assistance ;
• un moyen de contact entièrement automatisé. »

Autrement dit : lorsqu’un dispositif d’aide existe sur une interface, il doit être toujours positionné au même endroit dans chaque page appartenant au même ensemble de pages, afin que les personnes qui ont besoin d’aide sachent où le trouver.

En effet, certaines personnes en situation de handicap peuvent rencontrer des problèmes qui leur sont très particuliers et qui les empêchent d’atteindre leurs objectifs, comme trouver un document nécessaire à la saisie de données dans un formulaire, ou bien répondre à certaines questions.

Elles peuvent tout simplement abandonner la tâche qu’elles essayaient de réaliser si aucune aide n’est prévue, ou si l’aide est difficile à trouver.

Ce critère ne demande pas de fournir obligatoirement de l’aide aux utilisateurs et utilisatrices. En revanche, si une aide est présente, alors il exige qu’elle soit toujours présentée et atteignable dans le même ordre relatif du contenu des pages.

Peuvent être considérés comme des aides accessibles les mécanismes suivants :

• des coordonnées humaines : un numéro de téléphone, une adresse électronique, les heures d’ouverture, etc. ;
• un mécanisme de contact qui permet d’échanger avec quelqu’un, tel qu’un système de messagerie, un client de chat, un formulaire de contact, etc. ;
• un dispositif d’autoassistance tel qu’une foire aux questions à jour, une page « Comment faire », une page d’assistance, etc. ;
• un dispositif de contact entièrement automatisé, tel qu’un chatbot par exemple.

Ainsi, si un chatbot est présent, qu’il est situé visuellement en bas à droite de l’interface et présent dans le code juste avant le pied de page, alors les utilisateurs et utilisatrices doivent pouvoir le retrouver toujours à ces endroits-là approximativement, quelle que soit leur façon de naviguer.

---

Navigation par références de pages – A

D’après la définition en anglais du critère 2.4.13 Page Break Navigation :

« Pour chaque contenu comportant des références de pages, un mécanisme est disponible pour naviguer vers chaque référence de page. »

Ce critère s’applique particulièrement aux contenus qui font références à d’autres pages, par exemple des livres numériques ou tout autre contenu découpé en pages.

Ce critère sert à s’assurer que les références de numéro de page restent valables dans tous les contextes de consultation, que le contenu soit imprimé ou numérique notamment.

En effet, certaines publications numériques disposent de mécanismes de réarrangement des contenus entre les pages, en fonction de la taille de la police ou de l’écran par exemple.

De même, certaines technologies d’assistance permettent de modifier les paramètres d’affichage et donc de répartir les contenus de manière différente de ce qui est prévu initialement.

Du fait d’un réarrangement ou d’une répartition différente du contenu, la numérotation des pages pourrait se trouver modifiée.

Ainsi, une page référencée sous le numéro 45 dans sa version standard (ou dans sa version imprimée) pourrait devenir la page 76 parce que l’utilisateur ou l’utilisatrice a modifié l’affichage de sa liseuse par exemple.

Or, on souhaite s’assurer que les références de pages soient consistantes quelles que soient les modalités de présentation, et qu’il sera toujours possible de les retrouver.

Pour cela, il sera donc nécessaire de conserver dans les contenus ces indicateurs de nouvelle page, afin de conserver une référence commune entre toutes les versions d’un même document.

Une méthode proposée consiste à fournir un dispositif de navigation vers chaque page de la publication, par exemple sous forme de table des matières dynamique.

La destination de ces liens resterait ainsi la même, quelles que soient la présentation et la répartition du contenu.

---

Apparence du focus

Apparence du focus (minimum) — AA

D’après la définition en anglais du critère 2.4.11 Focus Appearance (Minimum) :

« Lorsque les composants de l’interface utilisateur reçoivent le focus du clavier, toutes les conditions suivantes sont vérifiées :

• zone contrastée : pour une zone de l’indicateur de prise de focus, le rapport de contraste entre les couleurs de l’état focalisé et non focalisé est de 3:1 au moins ;
• zone minimale : la zone contrastée est au moins aussi grande que :
  • le contour : le périmètre du composant (dans son état standard) avec une largeur de 1 pixel CSS au moins ou,
  • la forme : une ligne de 4 pixels CSS d’épaisseur le long du côté le plus court d’un composant (dans son état standard), et dont l’épaisseur ne fait pas moins de 2 pixels CSS.
• contraste adjacent : la zone contrastée de l’indicateur de prise de focus présente également un rapport de contraste d’au moins 3:1 par rapport aux couleurs adjacentes du composant, ou la zone contrastée présente une épaisseur d’au moins 2 pixels CSS ;
• pas entièrement masqué : l’élément qui reçoit le focus n’est pas entièrement masqué par du contenu créé par l’auteur. »

Ce critère répond aux besoins des utilisateurs et utilisatrices qui naviguent au clavier et qui ont besoin de se repérer dans la page pour savoir où ils se trouvent.

Certaines personnes ont également des déficiences visuelles qui les empêchent de percevoir les prises de focus sur les composants si elles ne sont pas assez larges ou assez contrastées.

Dans le RGAA, le critère sur la visibilité de la prise de focus ainsi que celui sur les contrastes des composants d’interface encadrent déjà en grande partie cette problématique.

Mais ce nouveau critère WCAG 2.2 formule de nouvelles exigences, notamment en ce qui concerne la taille minimale de l’indicateur de prise de focus.

En plus de veiller à ce que l’indicateur de prise de focus soit suffisamment contrasté, il sera désormais nécessaire que la zone de l’indicateur de prise de focus ait une largeur ou une épaisseur suffisantes, et que le composant qui reçoit le focus soit toujours visible.

Ainsi, les prises de focus en pointillés mesurant 1 pixel d’épaisseur ne pourront plus être considérées comme conformes puisque la zone de visibilité de la prise de focus serait alors réduite de 50 % de la taille initiale du composant. Il faudra en doubler voire tripler l’épaisseur.

En effet, puisque dans ce cas la bordure est entrecoupée d’espaces vides permettant de créer l’effet de pointillés, cela signifie que la longueur des pointillés, s’ils étaient mis bout à bout, ne couvrirait que la moitié du périmètre total de l’élément.

De même, l’indicateur de prise de focus par défaut dans les champs de formulaire (le curseur clignotant) ne sera plus considéré suffisant pour signifier la prise de focus.

Enfin, cet indicateur sera dorénavant considéré non conforme si l’élément qui reçoit la prise de focus est masqué partiellement ou complètement par un autre élément d’interface, par exemple par un en-tête fixé par-dessus lui, ou par une infobulle qui se superpose à lui.

Apparence du focus (amélioré) — AAA

Le nouveau critère 2.4.12 Focus Appearance (Enhanced), de niveau triple A, vient compléter le critère 2.4.11 de niveau double A que nous venons de voir.

La principale différence entre les deux est la taille minimale requise.

En effet, le critère 2.4.12 de niveau triple A requiert que la taille de la zone de visibilité de prise de focus soit égale au moins à 2 fois le périmètre (la longueur du contour) du composant.

---

Contrôles visibles – AA

D’après la définition en anglais du critère 3.2.7 Visible Controls :

« Lorsque des composants d’interface sont rendus visibles au survol ou à la prise de focus, les informations nécessaires pour identifier les composants disponibles sont visibles, sauf lorsque :

• les informations nécessaires pour identifier les composants de l’interface utilisateur sont disponibles par le biais d’un composant équivalent qui est visible sur la même page ou à une étape différente d’un processus à plusieurs étapes sans nécessiter le survol du pointeur ou le focus du clavier ;
• le composant est fourni spécifiquement pour améliorer l’expérience de la navigation au clavier ;
• un mécanisme est disponible pour rendre l’information visible de manière persistante ;
• il est essentiel de masquer les informations nécessaires à l’identification du composant. »

Ce critère a pour objectif d’aider les personnes ayant des troubles de la motricité, une vision réduite, ou encore des troubles cognitifs. En effet, elles peuvent avoir des difficultés à découvrir la présence des composants d’interface qui ne se révèlent que dans certaines conditions de manipulation, ce qui nécessite d’explorer finement l’interface.

Prenons un exemple. Imaginons un site e-commerce sur lequel une utilisatrice affiche son panier, pour vérifier la liste des produits qu’elle s’apprête à commander. Or, le bouton permettant de supprimer chaque produit est masqué par défaut, et ne s’affiche que lorsque le produit est survolé, ou bien lorsque le focus clavier atteint le bouton de suppression. Dans ce cas, on a un problème d’accessibilité.

En effet, ce type de comportement va poser problème aux personnes déficientes visuelles, dont la vue est trop réduite : au moment où le bouton est révélé, il peut s’afficher en dehors de leur zone de visibilité. Elles peuvent donc ne jamais le découvrir et ne pas savoir comment supprimer un produit de leur panier.

Cela va gêner également les personnes ayant des troubles cognitifs, pour qui il peut être difficile de comprendre quelles manipulations il est nécessaire d’effectuer pour atteindre ce bouton.

C’est pourquoi, pour ce type d’élément, le nouveau critère 3.2.7 va demander :

• soit de laisser les composants toujours visibles et de veiller à ce qu’ils soient suffisamment contrastés, sans condition de manipulation de la part de l’utilisateur ou de l’utilisatrice ;
• soit de fournir un mécanisme qui permet de révéler ces composants (sur le modèle d’un sélecteur de styles, ou color switcher) ;
• soit de fournir un composant équivalent visible et suffisamment contrasté sur la même page.

Le critère 3.2.7 ne s’applique pas aux composants qu’il est essentiel de masquer, ni à ceux qui n’auraient vocation à être rendus visibles que pour les personnes naviguant exclusivement au clavier.

---

Taille de la zone interactive (minimum) — AA

D’après la définition en anglais du critère 2.5.8 Target Size (Minimum) :

« Les zones interactives ont une surface d’au moins 24 par 24 pixels CSS, sauf dans les cas suivants :

• l’espacement : il y a un décalage d’au moins 24 pixels CSS entre la zone interactive et les autres zones interactives adjacentes ;
• en ligne : la zone interactive se trouve dans une phrase ou un bloc de texte ;
• essentiel : la taille de la zone interactive est essentielle à la transmission de l’information. »

WCAG 2.1 avait déjà introduit le critère 2.5.5 Taille des zones interactives (amélioré), de niveau triple A, qui exige que les zones interactives aient une taille minimale de 44 par 44 pixels CSS.

Le nouveau critère 2.5.8, de niveau double A, remplit la même fonction, mais ne requiert qu’une taille de 24 pixels par 24 pixels CSS.

De fait, ce critère répond aux besoins des personnes ayant des troubles de la motricité fine, pour qui pointer une zone interactive donnée peut être difficile, voire impossible, si celle-ci est trop petite.

Dans ce contexte, une taille minimale permet de limiter les erreurs de pointage (à la souris ou au toucher).

Les personnes utilisant des pointeurs peu précis seront également aidées par la mise en œuvre de ce critère, par exemple les personnes qui naviguent à l’aide d’un dispositif d’eye tracking.

Le critère 2.5.8 exige donc :

• soit de s’assurer que chaque zone interactive d’une interface (lien, bouton, zone réactive…) mesure au moins 24 pixels par 24 pixels CSS ;
• soit de s’assurer qu’il existe entre chaque zone interactive adjacente une distance d’au moins 24 pixels CSS.

Attention : les liens intégrés dans des phrases ne sont pas concernés par le critère.

---

Saisie redondante — A

D’après la définition en anglais du critère 3.3.8 Redundant Entry :

« Les informations déjà saisies une fois par l’utilisateur ou fournies à celui-ci et qui doivent être saisies à nouveau dans le même processus et dans la même session utilisateur sont :

• soit remplies automatiquement ;
• soit présentées à l’utilisateur pour que celui-ci puisse les sélectionner à nouveau.

Sauf dans les cas suivants :

• la ressaisie de l’information est essentielle,
• l’information est nécessaire pour assurer la sécurité du contenu,
• les informations saisies précédemment ne sont plus valables. »

Ce critère concerne les formulaires en plusieurs étapes, et vise à réduire les efforts cognitifs nécessaires pour pouvoir les remplir avec succès.

Les personnes ayant des troubles de la mémoire peuvent se retrouver bloquées si un formulaire demande de saisir à nouveau des informations qu’elles ont déjà saisies au préalable. Par exemple : devoir saisir une seconde fois son nom de famille.

De plus, devoir saisir plusieurs fois les mêmes données dans un même formulaire peut entraîner un stress chez certaines personnes et une fatigue intellectuelle qui va les amener soit à saisir des valeurs incorrectes, soit à abandonner la tâche.

C’est pourquoi le critère 3.3.8 exige, pour chaque formulaire en plusieurs étapes qui demande de saisir plusieurs fois certaines informations :

• soit que le formulaire remplisse automatiquement les champs concernés avec les données déjà saisies. Par exemple, prenons un formulaire d’achat, qui demande de saisir une adresse de facturation et une adresse de livraison. Si l’utilisatrice a déjà saisi l’adresse de facturation, et que l’adresse de livraison est la même, il doit alors être possible, depuis l’interface, de remplir automatiquement l’adresse de livraison sur la base des informations saisies pour l’adresse de facturation. Il pourrait s’agir par exemple d’une case à cocher qui permettrait de dupliquer automatiquement la saisie ;
• soit que le formulaire présente une liste des données déjà saisies par l’utilisateur ou l’utilisatrice, pour qu’il leur soit possible de les sélectionner à nouveau. Une solution consisterait par exemple à fournir une liste de valeurs possibles au moyen d’un mécanisme d’autocomplétion, alimenté par les saisies antérieures de l’utilisatrice dans le même formulaire.

Ce critère a prévu des exceptions pour certains cas particuliers, notamment pour des questions de sécurité.

Par exemple, il est courant qu’un formulaire de création de compte demande de saisir deux fois le même mot de passe. Dans ce cas, il est acceptable que l’utilisatrice doive bien saisir manuellement son mot de passe deux fois.

---

Un changement de niveau à signaler

Pour terminer, signalons que jusqu’à présent, le critère Focus Visible, déterminant la visibilité de l’indicateur de la prise de focus à l’écran, était initialement un critère WCAG de niveau AA.

Désormais ce critère passe au niveau A dans WCAG 2.2.

Ce critère correspond au critère 10.7 du RGAA (« Dans chaque page web, pour chaque élément recevant le focus, la prise de focus est-elle visible ? »), qui était déjà de niveau A.

En effet, comme le critère RGAA 10.7 est lié à deux critères WCAG (1.4.1 Use of Color A, 2.4.7 Focus Visible AA), le niveau du critère RGAA est déduit de l’ensemble des niveaux des critères WCAG reliés, en prenant en compte le niveau le plus exigeant.

---

Conclusion

Comme à chaque mise à jour des WCAG, gardez à l’esprit que tous les nouveaux critères proposés dans le document de travail du W3C ne feront peut-être pas partie de la version finale, et que certains seront peut-être modifiés selon les commentaires qui auront été récoltés.

Les critères WCAG 2.2. ne sont donc pas encore applicables aujourd’hui.

De plus, le contexte est encore plus spécifique en France. En effet, les obligations légales françaises découlent de la Directive européenne, qui déclare la norme européenne EN 301 549 comme référence pour l’accessibilité numérique.

Cela signifie qu’il faudra sans doute attendre encore un peu que cette norme européenne intègre les nouveaux critères WCAG 2.2, puis que la France les transpose à son tour dans le RGAA !