100 en accessibilité : la note qui ne veut rien dire

Publié le 15 mai 2026Mis à jour le 4 août 2026

10 min de lecture

Lighthouse
Audit
RGAA

Table des matières

Le faux positif

Tu viens de lancer un audit Lighthouse. Le score d'accessibilité s'affiche : 100/100. Vert. Parfait. Tu refermes l'onglet, satisfait. Le site est accessible.

Sauf qu'il ne l'est probablement pas.

Lighthouse vérifie environ 30 à 40% des problèmes d'accessibilité réels. Les 60 à 70% restants — la navigation clavier, l'expérience au lecteur d'écran, la pertinence des textes alternatifs, le comportement du contenu dynamique — aucun outil automatisé ne les détecte. Un score de 100 signifie que tout ce que la machine peut vérifier est correct. Pas que ton site est utilisable par tout le monde.

Cet article va te montrer ce que Lighthouse voit, ce qu'il ne voit pas, pourquoi l'IA ne comble pas encore l'écart, et comment tester ce qui compte vraiment.

Ce que Lighthouse voit

Lighthouse s'appuie sur axe-core, le moteur de test automatisé de Deque. Il vérifie ce qui a une réponse binaire dans le code — présent ou absent, correct ou incorrect :

Les textes alternatifs — est-ce que chaque image a un attribut alt ? (Pas si le texte est pertinent.)
Les contrastes — est-ce que le ratio entre le texte et le fond atteint le seuil minimum ? (Pas si l'information repose uniquement sur la couleur.)
Les titres — est-ce que la hiérarchie <h1> → <h2> → <h3> est respectée ? (Pas si les titres décrivent réellement le contenu.)
Les attributs ARIA — est-ce que les rôles et propriétés existent et sont valides ? (Pas si le comportement clavier correspond au rôle annoncé.)
Les labels de formulaire — est-ce que chaque champ a un <label> associé ? (Pas si le label aide à comprendre ce qui est attendu.)

Le pattern est toujours le même : Lighthouse vérifie la présence, jamais la pertinence. Il sait que ton image a un alt. Il ne sait pas si cet alt dit "image" ou s'il décrit réellement ce que l'image apporte.

C'est utile — ça attrape les oublis évidents, les régressions, les erreurs de syntaxe ARIA. Mais c'est un filet à grosses mailles. Tout ce qui demande du jugement passe au travers.

Ce que Lighthouse ne voit pas

Les problèmes d'accessibilité les plus impactants sont ceux qui demandent du contexte, du jugement, ou une interaction réelle. Aucun outil automatisé ne les détecte.

Lighthouse ne navigue pas ta page au clavier. Il ne sait pas si un utilisateur peut atteindre chaque élément interactif avec Tab, si le focus est visible, ou s'il reste coincé dans un piège. Il vérifie que tabindex n'a pas de valeur aberrante — pas que l'expérience de navigation a du sens.

L'ordre de lecture

Le lecteur d'écran lit le DOM dans l'ordre du code source, pas dans l'ordre visuel. Un élément positionné en haut de la page avec CSS mais placé en bas du HTML sera lu en dernier. Lighthouse ne compare pas l'ordre visuel à l'ordre du DOM — il faudrait un humain pour ça.

La pertinence des textes

Un alt="image" passe le test automatisé. Un lien "cliquez ici" aussi. Un aria-label="bouton" aussi. Techniquement, l'attribut est là et la valeur est une chaîne non vide. Mais un utilisateur de lecteur d'écran qui entend "lien, cliquez ici, lien, cliquez ici, lien, cliquez ici" en naviguant par liens ne sait pas où chaque lien l'emmène.

Le contenu dynamique

Une modale qui s'ouvre, un message d'erreur qui apparaît, un panier qui se met à jour — Lighthouse prend un instantané de la page au chargement. Il ne teste pas ce qui se passe quand l'utilisateur interagit. Si ta modale n'envoie pas le focus à l'intérieur, si ton message d'erreur n'a pas d'aria-live, si ton panier se met à jour en silence — le score reste à 100.

Les parcours utilisateur

Un formulaire en trois étapes peut passer chaque test automatisé individuellement. Mais si le passage de l'étape 2 à l'étape 3 ne déplace pas le focus, si le récapitulatif final n'est pas atteignable au clavier, si les erreurs de l'étape 1 ne sont pas annoncées quand on y revient — l'expérience est cassée. Lighthouse teste des pages, pas des parcours.

L'IA ne remplace pas l'audit

Face aux limites des outils automatisés, deux promesses circulent. La première est dangereuse. La seconde est encourageante. Aucune des deux ne supprime le besoin d'un expert.

Les overlays : le faux remède

Des entreprises vendent des overlays — une ligne de JavaScript qui promet de "rendre ton site accessible" automatiquement. En 2024, 25% des procès pour accessibilité aux États-Unis visaient des sites déjà équipés d'un overlay. Non pas la solution, donc, mais un aimant à contentieux. accessiBe, le plus connu d'entre eux, a été condamné à 1 million de dollars par la FTC pour avoir menti sur les capacités de son outil. UserWay, son concurrent, fait l'objet d'un recours collectif après qu'un client a été poursuivi malgré l'overlay en place.

La National Federation of the Blind — la plus grande organisation de personnes aveugles aux États-Unis — a publiquement déclaré qu'accessiBe "nuit activement à la capacité des utilisateurs de lecteurs d'écran à naviguer efficacement sur les sites web".

Ces outils ajoutent une couche de JavaScript qui modifie le DOM après chargement — exactement le type d'intervention qui dégrade la performance et déstabilise l'arbre d'accessibilité, j'en parle dans Trois factures, un seul code, zéro surcoût.

L'IA comme co-pilote, pas comme pilote

L'approche qui fonctionne est celle de Deque avec axe : l'IA ne remplace pas l'humain, elle le guide. Leurs Intelligent Guided Tests combinent des vérifications automatisées avec des questions que l'IA pose à un testeur humain — "ce texte alternatif décrit-il réellement l'image ?", "le focus se déplace-t-il correctement après cette action ?". Résultat : 80% de couverture contre 57% pour l'automatisé pur mesuré par le même rapport Deque. Mais les 80% reposent sur un humain qui répond aux questions — pas sur une IA qui décide seule.

C'est un domaine sur lequel je travaille — développer des outils capables d'atteindre ou de dépasser les 80% de couverture de Deque, mais sans nécessiter un humain aux manettes à chaque test. L'objectif : qu'une IA puisse juger la pertinence d'un texte alternatif, la cohérence d'un parcours clavier, la logique d'une hiérarchie de titres — les décisions qui aujourd'hui demandent un expert à chaque exécution. Mais même si cet objectif est atteint, les 20% restants resteront humains. Les cas limites, les contextes métier spécifiques, les parcours utilisateur réels avec de vraies personnes handicapées — aucune IA ne remplacera ça.

Tester pour de vrai

Lighthouse est le premier étage. Voici les suivants.

Les outils complémentaires

axe DevTools — l'extension navigateur de Deque, gratuite, qui utilise le même moteur que Lighthouse mais avec plus de règles et des résultats plus détaillés. C'est le meilleur point de départ après Lighthouse.

WAVE — l'outil de WebAIM qui affiche les problèmes directement sur la page, visuellement. Particulièrement utile pour repérer les erreurs de structure (titres, landmarks) et les contrastes insuffisants d'un coup d'œil.

Accessibility Insights for Web — l'extension de Microsoft qui visualise le parcours clavier directement sur la page (Tab Stops), vérifie les landmarks et propose des tests guidés pour les critères WCAG non automatisables. J'en parle dans Posez la souris.

Le test clavier

Pose ta souris et navigue ton site avec Tab. Je l'ai détaillé dans Posez la souris — c'est le test le plus simple et le plus révélateur. Si tu ne peux pas atteindre un élément, l'activer, ou en sortir, ton site a un problème qu'aucun outil automatisé ne détectera.

Le test au lecteur d'écran

Active VoiceOver (Cmd + F5) ou installe NVDA (téléchargement gratuit) et navigue ta page. On a détaillé les raccourcis et la méthode dans Les lecteurs d'écran ne lisent pas comme toi. L'arbre d'accessibilité dans les outils de développement est utile pour un premier diagnostic — mais rappelle-toi que c'est une radiographie, pas un examen clinique.

Le test utilisateur

Le dernier étage — et le plus riche en enseignements. Fais tester les parcours critiques de ton produit par des personnes extérieures à l'équipe, dans des conditions variées : navigateur différent, appareil mobile, lecteur d'écran activé, navigation clavier uniquement. Tu n'as pas besoin d'être en situation de handicap pour détecter la majorité des problèmes — un expert qui maîtrise VoiceOver et NVDA, ou simplement quelqu'un qui pose sa souris et navigue au clavier, trouvera des barrières qu'aucun outil automatisé ne verra.

Et si tu veux aller encore plus loin, inclure des personnes en situation de handicap dans tes tests apporte une dimension que même l'expert le plus compétent ne peut pas simuler — des habitudes de navigation, des stratégies de contournement, des attentes que seule l'expérience quotidienne construit.

Le vrai 100%

Tu peux obtenir 100/100 sur Lighthouse et exclure des millions de personnes. Tu peux passer chaque critère du RGAA ou des WCAG et avoir un site qui reste difficile à utiliser pour une personne handicapée.

Les référentiels sont le minimum vital — le socle légal, le plancher en dessous duquel tu es en infraction. Mais la conformité n'est pas l'accessibilité. La conformité dit que ton code respecte les règles. L'accessibilité dit que ton produit fonctionne pour tout le monde. La différence se mesure avec des humains, pas avec des scores.