Développement web
Lighthouse 100 ne prouve pas qu’un site est accessible
Accessibilité · Lighthouse · RGAA
Un score Lighthouse 100 rassure. Il ne prouve pourtant ni la conformité RGAA, ni la capacité d’un utilisateur à terminer un parcours réel.
- Signal Lighthouse repère des erreurs automatisables.
- Angle mort Le clavier, le focus, les modales et les formulaires exigent un test humain.
- Preuve Un audit crédible combine outil, parcours manuel et périmètre daté.
Repères vérifiés le 23 juin 2026. Lighthouse ouvre l’enquête ; il ne la clôture pas.
Le mythe
Le raccourci “100 Lighthouse = site accessible” est confortable, mais faux.
Le score Lighthouse a un avantage immense : il rend visible une partie de l’accessibilité dans un outil que les équipes connaissent déjà. En quelques secondes, il donne des alertes sur les contrastes, les noms accessibles, les labels de formulaires ou certains attributs ARIA. Pour une recette rapide, c’est précieux.
Le problème commence quand ce score devient une conclusion. Un 100 en accessibilité ne veut pas dire que le site est conforme au RGAA. Il ne veut pas dire qu’un utilisateur peut tout faire au clavier. Il ne veut pas dire qu’un lecteur d’écran comprend le parcours. Il ne veut pas dire qu’un formulaire est corrigeable, qu’une modale est utilisable, ou qu’un composant JavaScript respecte les attentes d’usage.
La bonne lecture est plus simple : Lighthouse est un thermomètre sur certains symptômes. Un thermomètre ne fait pas le diagnostic complet, mais il peut indiquer qu’il faut regarder de plus près.
Un score automatique peut ouvrir une enquête. Il ne peut pas la clôturer.
Ce que le score mesure
Lighthouse n’est pas le problème : c’est une première étape légitime.
Le score accessibilité de Lighthouse est construit à partir d’audits automatisés. La documentation Chrome indique qu’il s’agit d’une moyenne pondérée des audits d’accessibilité, et que chaque audit est traité en réussite ou échec. Autrement dit, Lighthouse ne regarde pas “l’expérience complète” : il évalue des règles détectables dans la page rendue.
Cette approche est utile quand elle reste à sa place. Elle repère vite les erreurs que l’on ne devrait plus laisser passer : image informative sans alternative, champ sans label, bouton sans nom accessible, langue de page absente, contraste insuffisant dans certains cas, attribut ARIA invalide, identifiants dupliqués, ordre de titres incohérent.
| Signal détecté | Ce que cela améliore | Ce que cela ne garantit pas | Contrôle à ajouter |
|---|---|---|---|
| Bouton avec nom accessible | Le bouton peut être annoncé par une technologie d’assistance. | Le libellé peut rester ambigu ou inutilisable dans le contexte réel. | Lire le parcours avec un lecteur d’écran et vérifier l’intention. |
| Champ avec label | Le champ est associé à une étiquette technique. | Le message d’erreur peut être absent, trop loin ou non annoncé. | Soumettre le formulaire vide, corriger l’erreur, terminer l’action. |
| Contraste suffisant | Certains couples texte/fond passent le seuil contrôlé. | Les états hover, focus, disabled, textes sur images ou contenus dynamiques peuvent échapper au test. | Tester les états réels et les composants clés. |
| ARIA valide | La syntaxe ARIA ne contient pas d’erreur évidente. | Un composant peut être valide en syntaxe et mauvais en interaction. | Vérifier le rôle, l’état, le clavier et l’annonce vocale. |
Les angles morts
Ce qu’un score automatique ne peut pas garantir.
Le W3C le formule sans ambiguïté : les outils d’évaluation aident à identifier des problèmes, mais ils ne peuvent pas vérifier automatiquement tous les aspects de l’accessibilité. Le jugement humain reste nécessaire. C’est exactement la zone où se joue la qualité réelle d’un site professionnel.
Un outil peut détecter qu’un bouton possède un nom accessible. Il ne sait pas toujours si ce nom permet de décider. Il peut détecter qu’un champ a un label. Il ne sait pas toujours si l’erreur sera comprise, annoncée, corrigée et reliée au bon champ. Il peut détecter qu’un élément est focusable. Il ne sait pas toujours si l’ordre de navigation suit le parcours attendu.
Clavier
Le test doit vérifier si chaque lien, bouton, champ, menu, onglet, accordéon, modale et étape de formulaire est atteignable sans souris.
Focus
Le focus doit être visible, logique, prévisible, non piégé, et replacé correctement après l’ouverture ou la fermeture d’un composant.
Compréhension
Les titres, liens, boutons, messages d’erreur et instructions doivent être compréhensibles hors contexte visuel.
Parcours
L’accessibilité se vérifie dans une action complète : chercher, filtrer, ouvrir, remplir, corriger, valider, revenir.
Test en 30 secondes
Débranchez votre souris : le test le plus simple révèle souvent plus qu’un score.
Avant même de parler RGAA, lancez un test court. Ouvrez une page importante de votre site, éloignez la souris, puis essayez d’atteindre et d’utiliser les éléments clés uniquement avec le clavier. Cette vérification ne prouve pas la conformité, mais elle détecte très vite les blocages grossiers.
Appuyez sur Tab et suivez le focus.
Chaque élément interactif doit être atteignable dans un ordre logique. Si vous ne voyez plus où vous êtes, le parcours est déjà fragile.
Ouvrez le menu, une modale ou un composant dynamique.
Le clavier doit permettre d’ouvrir, parcourir, activer et refermer le composant sans rester bloqué.
Soumettez un formulaire avec une erreur volontaire.
Le message doit être clair, proche du champ concerné, annoncé correctement et corrigeable sans repartir de zéro.
Utilisez Shift + Tab et Esc.
Un bon parcours clavier permet aussi de revenir en arrière, fermer une couche et récupérer le focus au bon endroit.
Exemple concret
Un site peut afficher 100 et bloquer une action réelle.
Le cas le plus fréquent n’est pas la page entièrement cassée. C’est plus discret : une page vitrine propre, une structure correcte, des labels présents, des couleurs acceptables, puis un composant qui bloque le parcours au moment important.
La démonstration visuelle de cet article résume un cas volontairement simple : une page peut obtenir un score automatique parfait au chargement, puis bloquer l’utilisateur après l’ouverture d’une modale. Visuellement, tout semble fonctionner. Au clavier, le focus reste derrière la modale, le bouton de fermeture n’est pas atteint, ou l’utilisateur ne peut pas revenir au bouton qui a ouvert la fenêtre. Le score est parfait, mais l’action commerciale est inaccessible.
Capture mentale à reproduire
Deux preuves doivent être lues ensemble.
- Signal automatique
La page obtient 100 en accessibilité Lighthouse : aucun défaut automatisable critique n’est remonté sur l’état testé.
- Interaction réelle
Une modale, un faux select, un menu mobile ou un formulaire devient impossible à terminer au clavier.
- Conclusion
Le score n’était pas faux. Il était incomplet. La décision “site accessible” était trop rapide.
C’est pour cette raison qu’un rapport sérieux doit documenter l’état testé, les pages, les composants, les outils et les limites.
Un div transformé en bouton ou en menu peut paraître interactif à la souris, mais ne pas entrer naturellement dans l’ordre de tabulation. Chrome rappelle que les contrôles personnalisés doivent être vérifiés manuellement au clavier. Le bloc ci-dessous illustre une erreur à éviter : ce n’est pas le bouton de diagnostic réel du site.
<div class="button-like" onclick="openModal()">
Ouvrir le diagnostic
</div>RGAA
Un audit RGAA ne se résume pas à une note automatique.
Le RGAA 4.1.2 organise les critères et tests en 13 thématiques : images, cadres, couleurs, multimédia, tableaux, liens, scripts, éléments obligatoires, structuration, présentation, formulaires, navigation et consultation. Ce périmètre dépasse largement ce qu’un seul score peut résumer.
La déclaration d’accessibilité officielle demande un état de conformité, un résultat de tests, des contenus non accessibles, un environnement de test, les outils utilisés, les pages vérifiées, un contact et des voies de recours. Ce formalisme existe pour une raison : l’accessibilité n’est pas une impression globale, c’est une vérification située.
C’est aussi ce qui protège la crédibilité d’une organisation. Dire “nous avons 100 Lighthouse” est utile. Dire “nous avons testé ces pages, ces composants, avec ces outils, à cette date, et voici les limites” est beaucoup plus solide.
Audit manuel
Ce qu’un audit manuel vérifie réellement.
L’audit manuel ne consiste pas à refaire Lighthouse à la main. Il consiste à regarder ce que l’outil ne peut pas conclure : l’usage réel, le sens des contenus, la cohérence des interactions et la capacité d’un utilisateur à terminer une tâche.
| Zone | Question d’audit | Risque si non testé | Preuve attendue |
|---|---|---|---|
| Navigation clavier | Peut-on atteindre, activer, fermer et quitter chaque composant ? | Un utilisateur reste bloqué ou ne peut pas convertir. | Journal de test clavier par gabarit. |
| Focus visible | Le focus est-il visible dans tous les états et sur tous les fonds ? | L’utilisateur navigue à l’aveugle. | Captures des états critiques. |
| Formulaires | Les erreurs sont-elles compréhensibles, annoncées et corrigeables ? | Le contact, l’achat ou la demande de devis échoue. | Scénario d’erreur documenté. |
| Lecteur d’écran | La structure, les boutons, les statuts et changements sont-ils annoncés correctement ? | Le parcours existe visuellement mais pas vocalement. | Contrôle avec technologie d’assistance. |
| Contenus | Les titres, liens, textes alternatifs et instructions ont-ils du sens ? | Le code passe, mais la compréhension échoue. | Revue éditoriale accessibilité. |
Méthode Edikka
Automatiser, tester, dater, documenter : la méthode Edikka.
Chez Edikka, un score automatique est traité comme une donnée d’entrée, pas comme une preuve finale. La preuve se construit par couches : outils, parcours humains, grille de critères, réserves, puis publication prudente des limites. Cette méthode évite deux erreurs : vendre un badge trop vite, ou rendre l’accessibilité inaccessible aux décideurs.
Sur edikka.com, la démarche publique distingue volontairement déclaration, rapport et observatoire. La déclaration donne le statut retenu. Le rapport liste les contrôles, les pages, les outils et les réserves. L’Observatoire explique comment lire des signaux publics sans confondre score, audit et conformité.
Outils
Lighthouse, WAVE, W3C, contrôles HTML et inspections navigateur servent à repérer rapidement les anomalies détectables.
Parcours
Les pages prioritaires sont testées comme de vrais chemins : naviguer, lire, ouvrir, remplir, corriger, valider.
Grille
Les critères applicables sont reliés à des gabarits, des preuves et des réserves, sans transformer un contrôle ciblé en conformité abusive.
Preuves
Le résultat doit être daté, relisible et testable à nouveau : c’est la différence entre une promesse et une preuve.
Conclusion
Le bon objectif n’est pas “avoir 100”. C’est ne pas bloquer l’usage.
Garder Lighthouse dans la boîte à outils est une bonne décision. Le transformer en certificat d’accessibilité est une mauvaise décision. Entre les deux, il y a une méthode : contrôler automatiquement ce qui peut l’être, puis vérifier humainement les parcours, les composants et les contenus qui font la vraie expérience.
Un site professionnel ne prouve pas sa qualité avec un badge isolé. Il la prouve avec des pages utilisables, des choix documentés, des corrections priorisées et des preuves datées. C’est plus exigeant. C’est aussi beaucoup plus crédible.
Cherchez le 100 Lighthouse, mais ne vous arrêtez pas là. Le vrai test commence quand quelqu’un utilise le site sans souris, sans contexte visuel évident et sans droit à l’erreur.
L’accessibilité est une preuve de qualité web, pas une note de dashboard.
Un site vraiment professionnel doit rester utilisable quand les conditions deviennent moins confortables : sans souris, avec un lecteur d’écran, avec une erreur de formulaire, sur mobile, avec fatigue, urgence ou contrainte temporaire.
Edikka relie donc accessibilité, UX, développement, SEO, visibilité IA et conversion. Le même effort qui rend un parcours plus robuste pour une personne handicapée rend souvent la page plus claire pour Google, les assistants IA, les équipes internes et les clients.
Comprendre sans deviner
Les titres, liens, boutons et erreurs doivent rester explicites sans dépendre uniquement du visuel.
Agir sans souris
Un parcours clé doit pouvoir être parcouru, corrigé et terminé au clavier.
Documenter sans surpromettre
Une démarche crédible publie le périmètre, la date, les outils, les tests humains et les limites.
Pour aller plus loin sur ce sujet
Des réponses complémentaires pour clarifier les points essentiels abordés dans cet article.
