Le client nous a contactés parce que son ancien prestataire venait de lui vendre un script qu’il fallait « juste coller dans le thème » pour rendre son site conforme à la loi. Le boniment avait fonctionné : un badge vert clignotait en bas à droite de chaque page, une pastille annonçait fièrement « site accessible », et la facture avait été réglée sans discussion. Le problème, c’est que rien n’avait changé dans le code.
Nous sommes intervenus six mois plus tard, après qu’une association de défense des droits des personnes handicapées a menacé d’engager une procédure. Ce billet raconte comment nous avons démonté ce widget, mesuré les dégâts qu’il causait réellement, puis reconstruit un plan d’audit RGAA sérieux à partir de zéro.
Ce que promettait le script
L’outil en question s’installait via une simple balise <script> injectée dans le footer.php du thème. Il ajoutait une icône flottante ouvrant un panneau de réglages : agrandissement du texte, changement de contraste, désactivation des animations, et un bouton « profil dyslexie » qui changeait la police en un caractère censé faciliter la lecture. Sur le papier, la liste des fonctionnalités impressionnait un client non technique.
En pratique, ce panneau se contentait de manipuler des styles CSS globaux au moment du chargement de la page, côté client, sans jamais toucher au HTML sous-jacent. Un lecteur d’écran comme NVDA ou VoiceOver n’en tirait strictement aucun bénéfice, puisque le problème n’était jamais dans l’apparence visuelle mais dans la structure du document.
Premier constat : le widget masquait les vrais problèmes
Avant même de lancer un audit RGAA formel, nous avons désactivé temporairement le script pour observer le site nu. Les résultats étaient sans appel : des formulaires de contact sans <label> associé, un menu de navigation entièrement à la souris, des images de produits sans attribut alt, un carrousel d’accueil qui piégeait le focus clavier et empêchait d’atteindre le reste de la page.
Pire encore, le widget introduisait ses propres obstacles : son bouton flottant n’avait pas de nom accessible, il interceptait la touche Échap pour son propre panneau au lieu de la laisser fermer les fenêtres modales du site, et son changement de contraste automatique cassait la lisibilité de certains textes en les rendant blancs sur fond blanc dans deux templates sur cinq.
Reconstruire un audit RGAA méthodique
Nous avons repris le référentiel général d’amélioration de l’accessibilité depuis le début, critère par critère, sur les cinq gabarits de page les plus visités du site : accueil, fiche produit, panier, contact, mentions légales. Chaque critère a été noté conforme, non conforme ou non applicable, avec une capture d’écran et une explication en langage clair destinée à l’équipe de développement.
- Structure des titres : deux pages sur cinq sautaient directement du
<h1>au<h4> - Formulaires : douze champs sans étiquette exploitable par un lecteur d’écran
- Navigation clavier : trois pièges à focus identifiés, dont le carrousel déjà cité
- Contraste : quarante-trois couples de couleurs sous le seuil de 4,5:1
Le vrai chantier de correction
Une fois le diagnostic posé, nous avons désinstallé définitivement le script d’overlay et entamé les corrections directement dans le thème WordPress : ajout de <label for> sur chaque champ, révision de la hiérarchie des titres via l’éditeur de blocs, retrait du piège à focus du carrousel en ajoutant une gestion correcte de tabindex et des flèches clavier, puis recalcul des couleurs de la charte graphique avec l’outil de contraste du W3C.
Un widget d’overlay ne fait jamais gagner de temps : il en fait perdre, car il faut d’abord convaincre le client que le premier chantier n’a servi à rien avant de commencer le vrai.
Notre verdict
Six semaines de travail ont été nécessaires pour corriger ce qu’un script prétendait résoudre instantanément. Le site a ensuite été soumis à un test avec des utilisateurs de lecteurs d’écran, qui ont confirmé que la navigation était devenue réellement praticable. Le budget initial dépensé dans l’overlay n’a servi qu’à retarder la mise en conformité et à donner un faux sentiment de sécurité juridique au client.
Si un prestataire propose une solution qui « rend un site accessible en une ligne de code », la meilleure question à poser est simple : quels critères précis du RGAA cette ligne corrige-t-elle, et comment le vérifier avec un lecteur d’écran réel ? Aucune réponse sérieuse à cette question doit alerter immédiatement.
