Le 5 octobre 2023, le World Wide Web Consortium a publié la version 2.2 des Web Content Accessibility Guidelines, près de sept ans après la précédente révision majeure. Contrairement à un changement de version radical, WCAG 2.2 conserve l’intégralité des critères de WCAG 2.1 et se contente d’en ajouter neuf nouveaux, ainsi que de retirer un seul critère jugé redondant. L’effort de mise à jour reste donc raisonnable pour un site déjà conforme au niveau précédent.
Voici les critères qui concernent le plus directement le travail quotidien d’un développeur WordPress, avec leur niveau de conformité (A, AA ou AAA) et la manière dont ils se traduisent dans un thème ou un plugin.
2.5.8 Taille des cibles (minimum), niveau AA
Ce critère impose une taille minimale de 24 par 24 pixels CSS pour toute cible interactive (bouton, lien, case à cocher), sauf exceptions listées (élément intégré dans une phrase de texte courant, cible entourée d’un espacement suffisant, ou contrôle dont la taille est imposée par l’agent utilisateur). Pour un développeur WordPress, ce critère touche directement les boutons de menu mobile, les icônes de réseaux sociaux dans le pied de page, et les puces de pagination d’un carrousel, des éléments fréquemment sous-dimensionnés dans les thèmes pensés d’abord pour l’esthétique desktop.
2.4.11 Focus non masqué (minimum), niveau AA
Ce critère exige qu’un élément recevant le focus clavier ne soit jamais totalement masqué par un autre contenu, comme un en-tête collant (position: sticky) ou une bannière de consentement aux cookies. C’est un défaut très courant sur les sites WordPress modernes : un menu fixe en haut de page masque régulièrement les premiers liens du contenu lors d’une navigation au clavier, qui reçoivent le focus mais restent visuellement cachés sous la barre fixe.
3.2.6 Aide cohérente, niveau A
Lorsqu’un mécanisme d’aide est proposé sur plusieurs pages d’un même site (lien vers une FAQ, coordonnées de contact, chat en direct), ce critère impose qu’il apparaisse au même endroit relatif de la mise en page d’une page à l’autre. Un site WordPress qui affiche un bouton de chat en direct uniquement sur certaines pages, ou à un emplacement différent selon le gabarit utilisé, échoue à ce critère.
3.3.7 Saisie redondante, niveau A
Ce critère interdit de redemander une information déjà saisie par l’utilisateur au cours d’un même processus, sauf nécessité de sécurité. Sur un tunnel de commande WooCommerce en plusieurs étapes, redemander l’adresse e-mail à l’étape de paiement alors qu’elle a déjà été saisie à l’étape de compte client constitue un manquement direct à ce critère.
3.3.8 Authentification accessible (minimum), niveau AA
Ce critère limite le recours aux tests cognitifs (résoudre un puzzle, mémoriser un mot de passe, recopier un code visuel) comme seule méthode d’authentification, sauf alternative proposée. Les CAPTCHA visuels classiques, encore largement utilisés sur les formulaires de connexion et de commentaires WordPress, sont directement concernés ; une alternative comme un lien magique envoyé par e-mail ou un CAPTCHA basé sur la reconnaissance de motifs simples plutôt que sur la lecture de texte déformé permet de répondre à cette exigence.
| Critère | Niveau | Zone WordPress la plus concernée |
|---|---|---|
| 2.5.8 Taille des cibles | AA | Boutons de menu, icônes, pagination |
| 2.4.11 Focus non masqué | AA | En-têtes collants, bannières cookies |
| 3.2.6 Aide cohérente | A | Chat, FAQ, coordonnées |
| 3.3.7 Saisie redondante | A | Tunnels de commande multi-étapes |
| 3.3.8 Authentification accessible | AA | CAPTCHA, formulaires de connexion |
Ce que WCAG 2.2 retire
Un seul critère disparaît par rapport à WCAG 2.1 : le critère 4.1.1 Analyse syntaxique, qui imposait un HTML sans erreur de balisage majeure (balises non fermées, identifiants dupliqués). Le groupe de travail a jugé ce critère devenu obsolète, les navigateurs et technologies d’assistance modernes gérant désormais correctement la plupart des erreurs mineures de balisage. Il reste néanmoins recommandé de produire un HTML valide, une bonne pratique de développement indépendamment de son statut dans le référentiel.
Un site conforme à WCAG 2.1 niveau AA n’est pas automatiquement conforme à WCAG 2.2. La bonne nouvelle : l’écart tient à neuf critères précis, tous documentés, tous vérifiables, ce qui rend la mise à niveau largement plus prévisible qu’un changement de version majeur.
En résumé
WCAG 2.2 confirme une tendance de fond : l’accessibilité mobile et tactile (taille des cibles), la cohérence des parcours (aide cohérente, saisie redondante) et l’authentification prennent une place croissante dans le référentiel. Pour un développeur WordPress, ces nouveaux critères se traduisent par des vérifications concrètes et ciblées, bien plus faciles à intégrer dans une recette de projet qu’une remise à plat complète.
