Les WCAG 2.2 pour les boutiques en ligne : les six nouveaux critères

Les WCAG 2.2 sont devenues une recommandation du W3C en octobre 2023. Elles reprennent tout le contenu des WCAG 2.1 et ajoutent neuf critères de succès, dont six aux niveaux A et AA, ceux que demandent d'habitude les lois et les contrats. Elles en retirent un : le 4.1.1 Analyse syntaxique, que les navigateurs ont rendu inutile. Voici ce que les six nouveaux critères changent pour une boutique en ligne, et comment les vérifier.

Qui demande les WCAG 2.2

Le modèle de déclaration d'accessibilité du gouvernement britannique se mesure aux WCAG 2.2 AA. Dans l'UE, la directive européenne sur l'accessibilité renvoie à la norme EN 301 549, qui s'appuie encore sur les WCAG 2.1 AA et passe aux 2.2. Le RGAA 4.1, en France, repose lui aussi sur les WCAG 2.1. Satisfaire les 2.2 dès maintenant évite d'y revenir, et les six nouveaux critères corrigent de vrais problèmes que les clients rencontrent tous les jours.

2.4.11 Focus non masqué (AA)

Quand un lien ou un bouton reçoit le focus clavier, il ne doit pas être entièrement caché par un élément que la boutique a placé par-dessus : un en-tête fixe, une barre « ajouter au panier » collante, un bandeau cookies, un bouton de chat. Les utilisateurs du clavier appuient sur Tab et ne voient rien bouger. La correction habituelle se fait en CSS : un scroll-padding-top et un scroll-padding-bottom sur la page, de la hauteur des barres, pour que le navigateur dégage l'élément qui a le focus.

2.5.7 Mouvements de glissement (AA)

Tout ce qui se fait en glissant doit aussi se faire par simples clics ou appuis : un curseur de fourchette de prix, une liste à réordonner, une carte à déplacer, un carrousel « glissez pour voir la suite ». Un curseur de prix accompagné de champs numériques passe ; un curseur seul échoue.

2.5.8 Taille des cibles (minimum) (AA)

Les boutons et les liens doivent mesurer au moins 24 pixels sur 24, ou laisser assez d'espace autour d'eux pour qu'un cercle de 24 pixels sur chacun ne touche pas le suivant. Les petites croix « retirer du panier », les flèches de quantité et les icônes de réseaux sociaux serrées sont les échecs habituels. Les liens dans une phrase sont exemptés.

3.2.6 Aide cohérente (A)

Si les pages proposent de l'aide — un lien de contact, une adresse e-mail, un numéro de téléphone, un chat — elle doit se trouver au même endroit, dans le même ordre, sur chaque page où elle apparaît. Un lien de contact dans le pied de page de la plupart des pages mais dans l'en-tête de la page de commande échoue.

3.3.7 Saisie redondante (A)

Ce que le client a déjà saisi dans un parcours ne doit pas lui être redemandé, sauf s'il est prérempli ou proposé au choix. À la commande, une case cochée « livrer à l'adresse de facturation » passe ; demander deux fois la même adresse, non.

3.3.8 Authentification accessible (minimum) (AA)

Se connecter ne doit pas dépendre de la mémoire ou de la recopie d'une information, sauf si quelque chose aide : les clients doivent pouvoir coller leur mot de passe et laisser un gestionnaire de mots de passe le remplir. Un champ de mot de passe qui empêche de coller, ou qui écarte les gestionnaires avec autocomplete="off", échoue. Utilisez autocomplete="current-password" sur le formulaire de connexion et "new-password" à la création d'un compte.

Ce qu'un logiciel peut vérifier

Quatre des six se repèrent automatiquement. Relyo vérifie gratuitement la taille des cibles (avec axe-core) et les champs de mot de passe sur chaque page ; Relyo Pro amène aussi chaque élément à l'écran comme le ferait le clavier et signale le focus caché sous une barre fixe, et compare les pages entre elles pour trouver l'aide qui change de place. Les mouvements de glissement et la saisie redondante demandent une personne : Relyo les liste avec ce qu'il faut vérifier. Chaque problème indique son numéro WCAG, avec un lien vers l'explication du W3C, à côté du critère RGAA quand il y en a un.