Un formulaire peut cocher toutes les cases d’un audit automatisé et rester pénible à remplir pour une personne aveugle. Ce constat surprend souvent les développeurs juniors : on imagine qu’un site « conforme » est un site « facile à utiliser ». Ce sont deux choses liées, mais distinctes, et confondre les deux mène à livrer des interfaces qui passent les tests sans jamais avoir été essayées par un vrai utilisateur.
La confusion vient de la façon dont on apprend l’accessibilité : par une liste de critères à cocher. Le RGAA (référentiel général d’amélioration de l’accessibilité) et les WCAG définissent des exigences vérifiables, un peu comme des tests unitaires pour l’interface. Mais un test unitaire qui passe ne garantit pas que le produit est agréable à utiliser, et c’est exactement la même limite ici.
Ce que mesure la conformité technique
Un critère RGAA du type « chaque champ de formulaire a-t-il une étiquette ? » vérifie une association programmatique : l’attribut for du <label> correspond-il à l’id du champ ? Techniquement, la réponse est binaire : oui ou non. Un lecteur d’écran annoncera bien le nom du champ. Le critère est satisfait.
Mais rien dans ce critère ne dit si l’étiquette est compréhensible, si l’ordre des champs a du sens, si les messages d’erreur permettent de corriger rapidement, ou si le formulaire complet peut se remplir en moins de deux minutes sans se perdre. La conformité s’arrête là où commence l’expérience réelle.
Trois exemples concrets de l’écart
Premier exemple : un menu d’onglets respecte le motif ARIA tablist/tab/tabpanel, chaque onglet est atteignable au clavier avec les flèches. Techniquement irréprochable. Mais si le contenu du panneau actif ne reçoit jamais le focus et que rien n’annonce le changement, un utilisateur de lecteur d’écran doit deviner que quelque chose a changé à l’écran, puis chercher le nouveau contenu à tâtons.
Deuxième exemple : une image de produit a un attribut alt renseigné, donc le critère « image porteuse d’information » est validé. Mais si le texte alternatif dit simplement « photo produit » au lieu de décrire la couleur ou la matière visible sur l’image, l’information utile n’est pas transmise. L’audit automatisé ne peut pas juger la qualité sémantique d’un texte, seulement sa présence.
Troisième exemple : un bouton « Ajouter au panier » a un contraste de couleur de 4,6:1, au-dessus du seuil de 4,5:1 exigé pour le texte normal. Conforme. Mais la zone cliquable ne fait que 20 pixels de haut sur mobile, rendant le geste difficile pour une personne avec un tremblement ou simplement en mouvement dans les transports.
Pourquoi cet écart n’est pas un échec du référentiel
Le RGAA ne prétend pas remplacer les tests utilisateurs, il fixe un socle vérifiable et opposable, notamment pour les obligations légales des services publics. Vouloir qu’un référentiel capture toute la qualité d’usage reviendrait à vouloir qu’une charte graphique garantisse un bon design : les deux fixent des règles nécessaires, pas suffisantes.
Un développeur qui comprend cette limite change sa façon de travailler : il traite la conformité comme un prérequis, pas comme un objectif final. Après avoir corrigé les critères automatisables, il reste une étape indispensable : naviguer réellement au clavier du début à la fin d’un parcours, puis avec un lecteur d’écran, en se posant une question simple à chaque étape : « Est-ce que je comprends où je suis et ce qui vient de se passer ? »
Comment intégrer ce contrôle dans un projet WordPress
- Après chaque fonctionnalité livrée, tester le parcours complet uniquement au clavier (tabulation, entrée, échap, flèches).
- Activer VoiceOver ou NVDA sur les pages critiques (tunnel de commande, formulaire de contact) au moins une fois par sprint.
- Documenter les frictions constatées séparément des non-conformités RGAA, car elles n’ont pas le même statut ni la même urgence.
- Faire relire les libellés et messages par une personne extérieure au projet, pour vérifier leur clarté réelle.
Un audit automatisé dit ce qui est cassé. Seul un vrai parcours dit ce qui est pénible. Les deux sont nécessaires, aucun ne remplace l’autre.
En résumé
Accessible et utilisable ne sont pas synonymes : le premier terme décrit une conformité vérifiable, le second une expérience vécue. Un site WordPress peut afficher un score d’audit excellent et rester frustrant pour une personne en situation de handicap si personne n’a testé le parcours réel. La bonne pratique consiste à traiter les critères techniques comme un plancher, puis à consacrer du temps, même court, à des tests d’usage au clavier et au lecteur d’écran avant chaque mise en production.
