Le 20 Juillet dernier la mise à jour de la version 2.2 du WCAG a été publiée en “Proposed Recommendation”. Cette version devrait être la dernière avant la publication car la publication finale est prévue en Août 2023. Le but de cet article est donc de présenter les modifications qui pourront être validées dans la prochaine version de WCAG 2.2, même si elles ne sont pas encore applicables à ce jour.

Les conséquences sur le RGAA

En soi, la publication d’une nouvelle version WCAG (Web Content Accessibility Guidelines) n’a pas d’impact direct sur le RGAA (Règlement Général d’Amélioration de l’Accessibilité). Le RGAA se limite à appliquer la directive européenne publiée en décembre 2018 (quelques mois après la version 2.1 des WCAG). Tant que cette directive n’est pas mise à jour, les WCAG 2.2 ne seront pas applicables en France. Il faudra malgré tout s’attendre à une mise à jour de la directive dans les mois qui suivront la publication finale de WCAG 2.2.

Quels sont les changements de la version 2.2 ?

Dans cette nouvelle version, 1 critère a été supprimé et 9 critères ont été ajoutés :

• 2 critères niveau A
• 4 critères niveau AA
• 3 critères niveau AAA (2 sont des restrictions relatives à des critères AA)

Adieu critère 4.1.1 “Parsing”

L’objectif de ce critère était de s’assurer de la correcte interprétation du contenu par les agents utilisateurs et les technologies d’assistance. Or, depuis la publication de WCAG 2.0 en 2008, les navigateurs ont amélioré leur gestion des erreurs d’analyse; il en est de même pour les technologies d’assistance qui se basent maintenant uniquement sur l’interprétation du navigateur et non plus sur leur propre analyse du balisage. Au fil du temps, ce critère est donc devenu obsolète.
Au niveau du RGAA ce critère WCAG est lié à 2 critères du RGAA 4.1.2 :

• Critère 8.1 [A] Chaque page web est-elle définie par un type de document ?
• Critère 8.2 [A] Pour chaque page web, le code source généré est-il valide selon le type de document spécifié ?

Le critère 8.1 étant uniquement lié à ce critère WCAG, il est très probable qu’il soit supprimé également et donc que cela entraîne une re-numérotation des critères.

2.4.11 (AA) et 2.4.12 (AAA) Prise de focus non masquée

Le nouveau critère 2.4.11 indique que “Lorsqu’un composant d’interface reçoit le focus clavier, celui-ci ne doit pas être entièrement masqué par le contenu créé par l’auteur”.

Impacts utilisateurs

L’objectif est de :

• Permettre aux utilisateurs naviguant uniquement avec le focus clavier de voir le composant qui reçoit le focus;
• Permettre aux utilisateurs a vision limitée ou malvoyants de voir les prises de focus qui ne sont pas assez larges;
• Permettre aux utilisateurs avec des limitations d’attention, des limitations de mémoire à court terme ou autres, de plus facilement repérer la localisation du focus.

Critères de réussite

Pour valider le critère de niveau AA, il est nécessaire de vérifier que chaque composant prenant le focus est toujours au moins en partie visible. Toutefois, ce critère ne concerne pas les composants qui peuvent être déplacés par l’utilisateur, les composants qui pourraient être ouverts par l’utilisateur ou les modales.
L’exemple le plus représentatif concerne les bandeaux de cookies qui se superposent au contenu et peuvent ainsi en partie masquer la prise de focus.

Le pendant de niveau AAA est le critère 2.4.12 qui lui demande à ce que le focus soit toujours visible dans sa totalité. L’exemple précédent serait donc considéré comme non conforme.

2.4.13 Apparence du focus (AAA)

Lorsque le focus est visible, celui-ci doit respecter les contraintes suivantes :

• le focus doit être au moins aussi grand qu’un périmètre de 2 pixels CSS de large du composant sans focus
• le contraste entre le focus et le composant soit d’au moins 3:1

Impacts utilisateurs

Ce critère a pour but de préciser l’apparence nécessaire du focus pour que les utilisateurs naviguant au clavier puissent visualiser le composant sélectionné . Ce critère sert également aux personnes avec des limitations d’attention, de mémoire à court terme ou autre, pour visualiser où le focus est situé.

Critères de réussite

Entourer avec un contour plein

Le focus doit entourer le composant concerné, soit via un contour rectangulaire soit via un contour correspondant à la forme de l’objet ayant le focus (par exemple en forme d’étoile pour un système de notation).

Aire du focus

Méthode 1

L’aire du focus doit représenter une surface équivalente au périmètre du composant sur 2px. Pour les formes principales on aura donc les formules suivantes :
Rectangle :
2 x Périmètre = 2 x (hauteur x largeur x 2)
Cercle :
2 x (2 x π x Rayon)
Rectangle avec des coins arrondis
2 x (hauteur x largeur x 2) – (16 – 4 π )Rayon
Pour ce critère, il faut rester pragmatique et considérer que si l’auditeur est obligé d’utiliser des calculs complexes pour vérifier la taille du focus c’est que celui-ci devrait être agrandi.

Méthode 2

La totalité de l’apparence du composant est modifiée, dans ce cas le critère est considéré comme valide.

Bien qu’elle soit valide, cette technique n’est pas à privilégier car elle peut créer des gênes pour certains utilisateurs.

Méthode 3

Si le focus est visible par un mécanisme d’ombre ou de dégradé, seule la zone respectant le contraste de 3:1 doit être prise en compte dans le calcul de l’aire.

Contraste

Le contraste entre la couleur du focus et la couleur de chaque côté du focus doit être d’au-moins 3:1.

2.5.7 Mouvements de glisser-déposer (AA)

Les mouvements de “glisser” doivent pouvoir être réalisés par un mécanisme sur un emplacement de pointage unique.

Impacts utilisateurs

Les utilisateurs utilisant des dispositifs de contrôles adaptés (trackball, simulateur de souris contrôlé par la voix…) peuvent avoir des difficultés à réaliser des opérations de cliquer-déplacer.
De même, les utilisateurs ayant des difficultés de mouvement peuvent éprouver des difficultés à maintenir le clic tout en déplaçant le pointeur par exemple.

Critères de réussite

Une méthode alternative à la fonctionnalité doit être proposée, cette méthode permet d’accéder aux mêmes fonctionnalités mais avec une action sur un point unique de l’écran.
Cela peut prendre différentes formes, comme :

• Des contrôles haut, bas, gauche, droite pour se déplacer sur une carte;
• Un menu contextuel affiché au clic droit pour déplacer un élément dans une autre liste;
• Un slider qui pourrait être déplacé en cliquant directement sur la ligne de slide;
• Un champ de saisi permettant de saisir une valeur sélectionnable sur un slider ou un contrôleur circulaire (comme une roue chromatique);
• Des boutons haut et bas pour organiser une liste…

2.5.8 Taille de la zone cliquable (AA)

La taille des composants cliquables (liens, boutons…) doivent être d’au moins 24×24 pixels CSS, sauf si :

• Le composant est assez espacé des autres éléments cliquables
• La fonctionnalité peut être activée depuis un autre emplacement dans la page qui respecte ce critère
• La zone cliquable est dans incluse dans un texte
• Les éléments dont la mise en forme est déterminée par le navigateur et qui ne sont pas modifiés par l’auteur
• Une présentation particulière est essentielle ou requise juridiquement pour que l’information soit transmise (par exemple des points sur une carte)

Impacts utilisateurs

Grâce à cela, les utilisateurs ayant des problèmes de motricité, qui empêchent de correctement cibler des zones cliquables avec la souris ou autre dispositif de pointage.

Critères de réussite

Taille

La taille de la zone cliquable doit être d’au moins 24 px par 24 px.

Espacement

Si la taille de l’élément est insuffisante, ce dernier doit comporter un contour vide de 24 pixels de diamètre centré sur l’élément cliquable.

Intégré

Si l’élément est intégré dans un texte non cliquable contraint par l’interlignage, alors ce critère n’est pas applicable.

Contrôlé par le navigateur

Les rendus par défaut de certains composants ne sont pas concernés par ce critère tant qu’ils ne sont pas modifiés par l’auteur (par exemple les input de type=date).

Essentielle

Si la taille de l’élément est essentielle pour comprendre l’information portée ou si elle représente une nécessité légale, alors ce critère n’est pas applicable. Par exemple, des points sur une carte qui seraient très rapprochés.

3.2.6 Aide (A)

Si une page Web contient l’un des mécanismes d’aide suivants :

• Coordonnées ;
• Mécanisme de contact humain ;
• Une option d’auto-assistance (FAQ, page d’aide) ;
• Un mécanisme de contact entièrement automatisé (chatbot)

Et que ces mécanismes sont répétés sur plusieurs pages au sein d’un ensemble de pages, alors ils doivent apparaître dans le même ordre relatif sur les différentes pages, à moins qu’une modification ne soit initiée par l’utilisateur (comme l’utilisation du zoom, ou le changement d’orientation de la page…).

Impacts utilisateurs

Les utilisateurs pouvant avoir des difficultés à situer les mécanismes d’aide peuvent être assistés si les mécanismes sont toujours situés au même emplacement dans la page.

Critères de réussite

Lorsqu’une page contient un mécanisme d’aide (coordonnées, formulaire de contact, système d’auto-assistance ou système automatisé), celui-ci doit être placé au même emplacement (dans le code) dans l’ensemble de page.

3.3.7 Entrées redondantes (A)

Les informations précédemment saisies par ou fournies à l’utilisateur qui doivent être saisies à nouveau dans le même processus sont :

• Soit rempli automatiquement,
• Soit sélectionnables par l’utilisateur.

Sauf quand :

• La ressaisie des informations est indispensable ;
• Les informations sont nécessaires pour assurer la sécurité du contenu, ou ;
• Les informations saisies précédemment ne sont plus valides.

Impacts utilisateurs

Pour ceux qui ont des troubles cognitifs, la fatigue mentale est une réalité bien présente. À mesure que la fatigue augmente, la probabilité que l’utilisateur fournisse des informations incorrectes ou abandonne complètement le processus augmente également.
Certains utilisateurs concernés par des troubles de la mémoire ont du mal à se rappeler des informations, même si ces informations ont été saisies récemment. L’un des objectifs de ce critère de succès est de minimiser la dépendance à la mémoire de l’utilisateur afin que l’utilisateur puisse terminer un processus.
Exiger des personnes qu’elles se souviennent des informations saisies précédemment peut les amener à abandonner ou à ressaisir les mêmes informations de manière incorrecte.

Critères de réussite

Deux possibilités pour satisfaire ce critère :

• Le service doit remplir automatiquement les informations des champs concernés ;
• Ou bien le service doit rendre disponible la sélection des informations par l’utilisateur. Ces informations doivent se trouver sur la même page, visible par défaut (idéalement mais ce n’est pas obligatoire il peut se trouver dans des mécanismes de discolsure ou de tooltip).
• Par exemple, cela peut prendre ces formes différentes :

1. Mettre à disposition une liste déroulante des données déjà saisies précédemment pour sélectionner la donnée qu’on souhaite récupérer ;
2. Afficher les informations saisies précédemment pour laisser l’utilisateur les copier puis les coller ;
3. Mettre à disposition une case à cocher pour remplir les entrées avec les mêmes valeurs que celles saisies précédemment (par exemple, mon adresse de facturation est la même que mon adresse de livraison).

3.3.8 et 3.3.9 Authentification accessible (AA) et Authentification accessible (sans exception) (AAA)

Un test de fonction cognitive (tel que se souvenir d’un mot de passe ou résoudre une énigme) n’est pas nécessaire à une étape quelconque d’un processus d’authentification, sauf si cette étape fournit au moins l’un des éléments suivants :

• Alternative : une autre méthode d’authentification qui ne repose pas sur un test de fonction cognitive.
• Mécanisme : un mécanisme est disponible pour aider l’utilisateur à accomplir le test de fonction cognitive.
• Reconnaissance d’objet : le test de fonction cognitive consiste à reconnaître des objets.
• Contenu personnel : le test de fonction cognitive consiste à identifier du contenu non textuel fourni par l’utilisateur sur le site web.

Impacts utilisateurs

Les utilisateurs ayant des troubles cognitifs relatifs à la mémoire, à la lecture, aux chiffres ou autres doivent être en mesure de se connecter quelque soit leurs capacités. Ainsi, les utilisateurs pouvant avoir des difficultés à mémoriser un mot de passe ou un identifiant ne seront pas bloqués et pourront se connecter facilement et de manière sécurisée.

Critères de réussite

Plusieurs techniques peuvent permettre de valider ce critère au niveau AA et AAA:

• Les champs sont correctement balisés pour être détectés et complétés automatiquement par le User Agent;
• Le site autorise le copier/coller dans les champs pour que l’utilisateur puisse utiliser un gestionnaire de mot de passe
• Le site utilise l’authentification à deux facteurs et autorise le copier-coller des éventuels codes envoyés (mêmes s’ils ont été envoyés sur un autre appareil)

Le critère 3.3.8 (AA) autorise, toutefois, deux méthodes supplémentaires de validation:

• Reconnaissance d’objet : Si le test est basé sur un contenu fourni par le site comme retranscrire un mot ou reconnaître une image fournie par le site, alors ce test cognitif peut être considéré comme une exception et donc valider ce critère
• Contenu personnel : En tant que second facteur d’authentification, il peut être demandé à l’utilisateur de sélectionner un contenu (de préférence une image) qu’il aurait fournie lors de la création de son compte. Les contrôles sur du texte ne peuvent être considérés comme conformes pour ce critère car ils représentent une barrière pour un plus grand nombre d’utilisateurs.