WCAG 2.2 : enfin la publication tant attendue !

La longue route des WCAG 2.2

En 2021, nous avions publié un premier article pour présenter la mise à jour des WCAG 2.2. 9 nouveaux critères avaient été proposés à l’ajout. L’appel à commentaires aurait dû se terminer le 4 juin 2021.

Mais le premier appel à commentaires public a fait remonter des problématiques assez critiques pour que le document reparte en discussion.

Ainsi, certains critères prévus au départ ont subi des modifications importantes ; d’autres ont carrément été supprimés, tandis que les exigences d’autres critères ont été discutées sans relâche jusqu’à la publication des WCAG 2.2.

WCAG 2.2 : une recommandation enfin validée

Une fois toutes ces discussions achevées, ce sont donc 9 nouveaux critères qui font leur entrée définitive dans cette nouvelle version de la norme WCAG :

• 2.4.11 Focus non masqué (minimum) – AA
• 2.4.12 Focus non masqué (amélioré) – AAA
• 2.4.13 Apparence du focus – AAA
• 2.5.7 Mouvement de glissement – AA
• 2.5.8 Taille de la zone interactive (minimum) – AA
• 3.2.6 Aide cohérente – A
• 3.3.7 Saisie redondante – A
• 3.3.8 Authentification accessible (minimum) – AA
• 3.3.9 Authentification accessible (amélioré) – AAA

Nouveaux critères des WCAG 2.2

Visibilité de la prise de focus dans les WCAG 2.2

Trois des nouveaux critères des WCAG 2.2 améliorent la prise en charge de la visibilité du focus pour les personnes qui naviguent au clavier.

Ces critères améliorent la définition de cette visibilité, telle qu’elle est déjà définie dans le critère 2.4.7 Focus visible (qui correspond au critère 10.7 du RGAA 4).

2.4.11 Focus non masqué (minimum) — AA (double A)

Ce critère demande à s’assurer que les composants interactifs (liens, boutons, champs de formulaire, etc.) ne sont pas complètement masqués par un autre élément de la page au moment où ils reçoivent la prise de focus.

Sont particulièrement concernés les composants qui se trouveraient derrière un autre composant fixe : par exemple, des liens dans un texte qui seraient masqués par des éléments fixes à l’écran, comme un en-tête de page, un pied de page, ou encore une fenêtre non modale.

En effet, lorsque des composants interactifs se retrouvent derrière des éléments fixes, il est impossible de percevoir où se situe la prise de focus, même si celle-ci reste fonctionnelle.

Le critère précise bien que la prise de focus ne doit « pas être entièrement masquée ». Ainsi, il n’est pas obligatoire de voir le composant dans sa globalité au moment où il reçoit la prise de focus : cette exigence est par ailleurs couverte par le critère AAA (triple A) suivant.

2.4.12 Focus non masqué (amélioré) — AAA (triple A)

Ce critère est une extension du critère 2.4.11 Focus non masqué (minimum), à la différence que le critère 2.4.12 requiert que tout le composant soit visible au moment où il reçoit le focus.

2.4.13 Apparence du focus — AAA (triple A)

Ce critère détermine une taille minimale (2 fois le périmètre de la zone interactive) et un contraste minimal pour la prise de focus.

Il faut déterminer le périmètre de chacun des composants pouvant recevoir le focus, et le comparer à la surface occupée par l’indicateur de prise de focus.

Il y a assez peu de problèmes pour les formes rectangulaires où la règle 2 x (Longueur + Hauteur) de calcul du périmètre s’applique sans détour. Mais dès que le composant présente des bords arrondis, ou bien si sa forme n’est pas rectangulaire (cercle, étoile, etc.), alors le calcul de la surface devient plus complexe.

Une fois le périmètre calculé, il faut le multiplier par 2 pour obtenir la surface minimale que doit occuper la prise de focus.

L’indicateur de prise de focus peut avoir n’importe quelle forme : il n’y a en effet aucune obligation à ce que ce soit une bordure tout autour du composant. Il peut donc s’agir d’une bordure inférieure, ou bien d’un cercle, etc. La seule exigence ici, c’est que l’indicateur du focus possède une surface d’au moins 2 fois le périmètre du composant.

Ainsi, après avoir déterminé si le focus a la surface minimale, il faut comparer la couleur de cette surface entre les états non-focus et focus, et vérifier qu’il y a bien un rapport de contraste de 3:1 au moins.

Autres nouveaux critères dans les WCAG 2.2

2.5.7 Mouvement de glissement — AA (double A)

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

En effet, les personnes ayant des troubles moteurs ne peuvent pas effectuer de glissement de manière précise.

Ces personnes vont rencontrer des difficultés pour terminer une tâche si la réalisation d’un mouvement basé sur un glissement est la seule méthode proposée pour cela. De plus, certaines personnes ne peuvent pas maintenir le pointeur enfoncé le temps qu’une action soit réalisée.

Enfin, les mouvements par glissement sont tout autant impossibles à réaliser pour des personnes naviguant avec des technologies d’assistance qui n’impliquent pas de contact physique avec leur ordinateur, tablette ou smartphone, telle qu’un logiciel de commande vocale.

Contrairement aux gestes complexes ^[1], il est question ici d’actions dont seuls les points de départ et d’arrivée du mouvement sont pris en compte. La trajectoire elle-même n’a pas d’importance, car les points intermédiaires n’ont pas d’influence sur le résultat final.

Exemple

Imaginons une application de gestion de projets dans laquelle on déplace 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 permet de réaliser le même déplacement sans devoir effectuer soi-même un geste de glissement.

Une alternative accessible consisterait alors à sélectionner le projet à déplacer en cliquant sur un bouton ou une case à cocher associés à l’item, et de le déplacer dans la colonne « Terminé » en cliquant sur cette colonne de destination. Il serait ainsi possible de déplacer l’élément sans effectuer de mouvement de glissement.

2.5.8 Taille de la zone interactive (minimum) — AA (double A)

Ce critère est une exigence réduite du critère de niveau AAA (triple A) qui était apparu dans les WCAG 2.1 : 2.5.5 Target Size (Enhanced), qui lui, réclame une taille de 44 par 44 pixels CSS.

Ces deux critères permettent de s’assurer que toutes les zones interactives (liens, boutons, champs de formulaires, etc.) ont une taille suffisante ou sont assez éloignées les unes des autres.

Cela réduit le risque d’activer par erreur un composant interactif pour les personnes ayant des troubles de la motricité fine (tremblements, difficulté à pointer avec précision sur un écran).

Ainsi, pour chaque zone interactive dont la largeur ou la longueur est inférieure à 24 pixels, il faut désormais vérifier :

• que la cible s’inscrit dans un cercle de 24px de diamètre sans se superposer à d’autres cibles (ou le cercle d’autres cibles) ;
• ou bien qu’un composant dans la page, qui répond aux exigences de ce critère, permet de réaliser la même action ;
• ou bien que la cible est contenue dans une phrase ou un autre contenu en ligne ;
• ou bien que la taille de la cible n’est pas modifiée par l’auteur (par exemple, des champs de saisie dont la taille serait insuffisante, mais dont l’apparence est définie par les paramètres de présentation du navigateur uniquement, sans surcharge CSS de l’auteur du document HTML) ;
• ou bien que la présentation initiale est essentielle, c’est-à-dire dans des cas où la densité des cibles interactives peut être trop grande pour permettre de répondre aux exigences de ce critère, par exemple dans le cas de graphique ou cartes interactives.

3.2.6 Aide cohérente – A (simple A)

Si un module d’aide est présent sur le site, alors il doit toujours être présenté et atteignable dans le même ordre relatif par rapport au contenu de chaque page au sein d’un ensemble de pages.

Il rejoint les critères 12.2, 12.4 et 12.5 du RGAA 4.1 qui demandent à ce que le plan du site, le menu de navigation principale et/ou le moteur de recherche soient présentés de manière cohérente dans chaque ensemble de pages.

En effet, certaines personnes handicapées se construisent des repères de navigation lorsqu’elles abordent un site web. Positionner ces éléments centraux dans la navigation (menu, aide, etc.) de manière identique entre les pages est une aide précieuse pour qu’elles n’aient pas à les rechercher en permanence.

C’est le cas notamment des personnes malvoyantes qui augmentent beaucoup le niveau de zoom du texte affiché à l’écran, et qui ont rarement une vision globale de page. Elles se créent alors une représentation de la page pour savoir où déplacer la loupe afin d’atteindre les éléments désirés (dans notre cas, les modules d’aide).

Ainsi, les mécanismes suivants peuvent être considérés comme des modules d’aide accessibles  :

• des coordonnées de contact humain : un numéro de téléphone, une adresse électronique, les heures d’ouverture pour joindre le service de support, etc. ;
• un mécanisme de contact qui permet d’échanger avec quelqu’un, tel qu’un système de messagerie, un client de messagerie instantanée, un formulaire de contact, etc. ;
• un dispositif d’auto-assistance, tel qu’une foire aux questions à jour ou bien une page « Comment faire ? », etc. ;
• un dispositif de contact entièrement automatisé, tel qu’un chatbot par exemple.

3.3.7 Saisie redondante – A (simple A)

Ce critère vise à réduire les efforts cognitifs nécessaires pour remplir certains formulaires avec succès, en limitant les saisies de données redondantes.

Les personnes ayant des troubles de la mémoire peuvent se retrouver bloquées si un formulaire demande de saisir 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 et une fatigue cognitive qui peut amener soit à saisir des valeurs incorrectes, soit à abandonner la tâche.

Le critère 3.3.7 des WCAG 2.2 exige donc, pour chaque processus qui demande de saisir plusieurs fois certaines informations (formulaire en plusieurs étapes par exemple) :

• soit que le formulaire remplisse automatiquement les champs concernés avec les données déjà saisies. Par exemple, dans le cas d’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.

Cas particuliers

Ce critère prévoit 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 comptes demande de saisir deux fois le même mot de passe. Dans ce cas, il est acceptable que l’utilisatrice remplisse manuellement son mot de passe deux fois.

3.3.8 Authentification accessible (minimum) — AA (double A)

Ce critère garantit l’existence d’une méthode d’identification accessible, facile à utiliser et sécurisée pour que les personnes concernées par certains troubles cognitifs puissent toujours s’identifier.

Ainsi, les méthodes d’identification des sites web ne doivent pas reposer exclusivement sur les fonctions cognitives, telles que la mémorisation à court ou long terme.

En effet, la mémorisation d’un nom d’utilisateur ou d’un mot de passe spécifique à un site web ou à une application relève d’un test de fonction cognitive, par exemple :

• mémoriser des chaînes de caractères aléatoires ;
• réaliser un geste particulier sur un écran tactile ;
• identifier des images contenant un objet spécifique.

Or, pour des personnes ayant des déficiences cognitives, ces tests-là nécessitent un effort cognitif très élevé, quand ce ne sont pas des tâches tout simplement impossibles à réaliser pour elles.

Ainsi, lorsqu’un test faisant appel à des fonctions cognitives est utilisé, une autre méthode d’authentification doit être proposée :

• soit fournir à l’utilisatrice une alternative pour s’authentifier qui ne repose pas sur un autre test de fonction cognitive ;
• soit permettre à l’utilisatrice d’utiliser un mécanisme d’aide au remplissage.

C’est pourquoi le critère 3.3.8 des WCAG 2.2 est conforme si les deux conditions suivantes sont remplies :

• l’authentification sur un site web repose sur le remplissage d’un identifiant (nom d’utilisateur ou adresse e-mail) et d’un mot de passe comme méthode d’authentification, d’une part ;
• l’authentification permet au navigateur ou à un gestionnaire de mots de passe de remplir automatiquement les champs d’autre part.

Ce critère est aussi conforme si l’authentification repose sur un test des fonctions cognitives qui est construit avec du contenu personnel de l’utilisatrice : par exemple si, lors de la création de son compte, l’utilisatrice peut téléverser une image qu’elle connaît puis, à sa prochaine connexion, sélectionner cette image-là parmi d’autres images aléatoires afin de passer le test anti-spam pour prouver son humanité.

3.3.9 Authentification accessible (amélioré) — AAA (triple A)

Ce critère est une extension du critère 3.3.8 Authentification accessible (minimum), en limitant les conditions à la présence d’une alternative ou d’un mécanisme d’aide.

Suppression de la validation du code source

C’est une première dans l’écriture des WCAG : un critère d’accessibilité a été supprimé !

En effet, le critère de succès 4.1.1 Analyse syntaxique (4.1.1 Parsing) est déclaré obsolète dans les WCAG 2.2 et est supprimé, avec la mention suivante :

« À l’origine, ce critère a été adopté pour résoudre les problèmes que les technologies d’assistance rencontraient dans l’analyse directe du langage HTML. Les technologies d’assistance n’ont plus besoin d’analyser directement le HTML et, par conséquent, ces problèmes n’existent plus. Les erreurs d’accessibilité qui ne répondent pas à ce critère ne répondent pas non plus à d’autres critères. Ce critère n’a plus d’utilité et est supprimé. »

Les documents des WCAG 2.0 et WCAG 2.1 ont été récemment mis à jour pour prendre en compte également cette modification statuant que le critère devait à présent être toujours considéré conforme.

Impact pour un audit RGAA

Ainsi, lorsque le RGAA sera mis à jour pour intégrer la nouvelle norme WCAG 2.2, les critères suivants disparaîtront aussi :

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

En attendant, même en l’absence de mise à jour du RGAA, nous vous recommandons donc de considérer ces critères dès maintenant systématiquement conformes.

Évolutions notables depuis la première recommandation candidate des WCAG 2.2 en 2021

Les WCAG 2.2 contiennent une nouvelle section qui liste les grands changements depuis les WCAG 2.1 : Change log.

Cette section permet de retracer la vie des critères de succès qui ont été ajoutés, puis qui ont changé de niveau, ou bien qui ont été supprimés le temps de l’écriture de la nouvelle version de la norme.

Y est mentionnée notamment la suppression de certains critères WCAG qui devaient paraître dans la norme, mais qui ont été supprimés depuis, et dont nous avions parlé dans notre premier article sur les WCAG 2.2 en 2021.

Toutefois, la suppression de ces critères n’a pas toujours suscité les mêmes réactions :

• la disparition des critères « Navigation par références de pages » (Page Break Navigation) et « Contrôles visibles » (Visible controls) n’a pas beaucoup fait parler d’elle ;
• au contraire, la disparition du critère « Apparence du focus (amélioré) » a suscité de nombreux débats. Ce critère était prévu initialement au niveau AA (double A) (nous vous en parlions déjà en 2021), mais il termine sa course au niveau AAA (triple A) dans la recommandation officielle, c’est-à-dire en dehors de l’obligation légale.

On voit également apparaître deux sections informatives listant les critères qui peuvent être impliqués dans des questions de confidentialité et de sécurité.

Publication des WCAG 2.2 : pour conclure

Le manque de techniques associées à chacun des 9 nouveaux critères des WCAG 2.2 va rendre un peu plus difficile leur mise en application.

Néanmoins, les documentations « Understanding WCAG » de chaque critère ont été très travaillées, et regorgent de détails et d’exemples d’implémentation conformes et non conformes pour faciliter la prise en main des nouveaux critères. Nous vous invitons fortement à les parcourir !

Par ailleurs, sur les 9 critères ajoutés dans les WCAG 2.2., seuls 6 critères entrent dans l’obligation légale (simple A et double A).

Pour évaluer la conformité, ce sont surtout les critères 2.4.11 Focus non masqué (minimum) et 2.5.8 Taille de la cible (Minimum) qui pèseront sur le temps global dédié aux audits d’accessibilité.

Les autres critères sont très contextualisés (Mouvements de glissement, Saisie redondante, Authentification accessible), donc peu courants et/ou assez simples à évaluer (Aide cohérente).

Il nous faut maintenant attendre qu’une version révisée de la norme EN 310 549 intègre ces nouvelles modifications ^[2] et que le RGAA se mette à jour à son tour.

D’ici là, chez Access42, nous nous attachons à préparer tout ce qu’il faut pour démarrer la traduction en français des WCAG 2.2 avec l’ensemble des personnes qui se sont portées volontaires. Vous pouvez suivre la progression de la traduction au fur et à mesure !