Trois chiffres qui ne mesurent pas la même chose
En 2017, le Government Digital Service britannique a testé dix outils sur une page comportant 143 obstacles connus. Le meilleur outil en a trouvé 41 %, le moins performant 17 %, et 29 % des obstacles n’ont été détectés par aucun. La page avait été volontairement truffée d’erreurs et les outils dataient de 2017, mais la conclusion tient toujours : on ne peut pas se fier aux outils seuls.
Deque, l’éditeur du moteur axe-core sur lequel s’appuie aussi Google Lighthouse, a indiqué en 2021 que les règles automatiques couvraient en moyenne 57 % des problèmes relevés dans plus de 2 000 de ses propres audits. Ce pourcentage est calculé en volume : les problèmes fréquents, comme un contraste insuffisant, pèsent plus lourd. Il s’agit d’une étude menée par l’éditeur lui-même.
Le chiffre souvent cité de « 20 à 30 % » mesure encore autre chose : la part des critères de succès WCAG qu’un outil est capable de tester. Ces trois chiffres ne sont donc pas comparables entre eux.
Ce qu’un outil peut évaluer seul
Quand un critère porte sur un élément présent ou absent du code, une règle peut statuer pour la page testée :
- images sans alternative textuelle, boutons et liens sans nom accessible, champs de formulaire sans étiquette
- contraste du texte inférieur à 4,5:1 (3:1 pour le texte de grande taille), mesuré sur la page affichée
- attribut
langabsent ou invalide, page sans titre, identifiants en double auxquels renvoient des étiquettes - balise meta viewport qui bloque le zoom ou fige la largeur, contenu qui clignote ou diffuse du son sans action de l’utilisateur
- CSS qui supprime le contour de focus sans le remplacer par un indicateur visible, valeurs positives de
tabindex
Même dans ces cas, la règle ne juge que ce qu’elle voit. Savoir si l’alternative textuelle décrit bien l’image, ou si un titre décrit vraiment sa section, relève toujours d’un jugement humain.
Ce que seule une personne peut évaluer
D’autres critères dépendent du sens, de l’enchaînement ou d’un comportement dans le temps. Aucune règle ne peut dire si :
- l’ordre de lecture reste logique une fois la mise en page retirée (1.3.2)
- le focus clavier peut sortir de chaque composant, par exemple d’une fenêtre de consentement aux cookies ou d’un sélecteur de date (2.1.2)
- un message d’erreur suggère comment corriger la saisie (3.3.3), ou si une étape de paiement peut être vérifiée et corrigée avant l’envoi (3.3.4)
- un message d’état comme « produit ajouté au panier » est restitué par le lecteur d’écran sans déplacer le focus (4.1.3)
- les sous-titres et l’audiodescription correspondent à ce qui est dit et montré (1.2.x)
Ce que nous avons mesuré sur de vrais sites
Le 21 octobre 2026, nous avons combiné l’audit d’accessibilité de Lighthouse et les contrôles propres à Sitequiry (HTML et feuilles de style liées) sur une page de deux sites réels. Nous avons compté combien des 55 critères de succès WCAG 2.2 de niveaux A et AA obtenaient un résultat automatique : problème détecté, aucun problème trouvé, aucun élément de ce type sur la page, ou critère non applicable.
| Site | Critères avec un résultat automatique | Laissés à une personne |
|---|---|---|
| sitequiry.com, page d’accueil | 35 sur 55 | 20 |
| Site d’une administration municipale, page d’accueil | 35 sur 55 | 20 |
Sur les deux sites, ce sont les mêmes 20 critères qui restaient à évaluer par une personne, parmi lesquels l’ordre de lecture, les pièges au clavier, les flashs lumineux, les suggestions en cas d’erreur et les messages d’état. Quatre de ces 20 critères comparent plusieurs pages : même ordre des menus, même nom pour les mêmes liens, aide sur toutes les pages, plusieurs moyens d’accéder à une page. Une seule page ne suffit pas à les faire apparaître ; il faut explorer le site entier.
« Aucun problème trouvé » ne signifie pas « critère validé ». Les règles ont été exécutées sans rien relever ; une personne doit encore confirmer le critère pour l’ensemble du service.
Bien utiliser un test automatique
- Testez une page de chaque gabarit (accueil, catégorie, fiche produit ou article, formulaire, tunnel de commande), pas seulement la page d’accueil.
- Corrigez d’abord ce que signalent les règles : ce sont des problèmes concrets, en général peu coûteux à résoudre.
- Parcourez ensuite la démarche principale au clavier uniquement, puis une fois avec un lecteur d’écran (NVDA sous Windows, VoiceOver sur Mac ou iPhone).
- Relancez le test automatique après chaque modification importante : il repère les régressions que personne ne pense à rechercher à la main.
- Une déclaration de conformité suppose une évaluation humaine. Un score de 100 dans Lighthouse indique seulement que les audits automatiques n’ont rien trouvé.
Questions fréquentes
Un test automatique peut-il confirmer que mon site respecte les WCAG ?
Non. Il trouve certains problèmes et montre où rien n’a été relevé, mais plusieurs critères ne peuvent être évalués que par une personne. Le W3C le rappelle à propos des outils d’évaluation en général.
Un score d’accessibilité Lighthouse de 100 suffit-il ?
Il signifie qu’aucun audit automatique n’a échoué sur cette page. Il ne dit rien des vérifications que Lighthouse classe comme manuelles, ni des autres pages.
À quelle fréquence faut-il tester ?
Automatiquement après chaque modification importante et au moins une fois par mois ; manuellement dès qu’un gabarit, un formulaire ou le tunnel de commande change.
Sources
- Blog accessibilité de GOV.UK : What we found when we tested tools on the world’s least-accessible webpage (24 février 2017, en anglais)
- Deque : Automated testing identifies 57% of digital accessibility issues (10 mars 2021, en anglais)
- W3C WAI : Selecting Web Accessibility Evaluation Tools (en anglais)
Vérifiez l’accessibilité de votre page
Le test gratuit vérifie une page au regard des critères WCAG 2.2 A/AA et montre les premiers problèmes à corriger. Le Site Report vérifie jusqu’à 20 pages de votre site.