Tester l'accessibilité web : outils gratuits et tests manuels

Voici une histoire qu'on nous raconte souvent. Quelqu'un lance Lighthouse, obtient un beau 100 en vert pour l'accessibilité et passe à autre chose. Une semaine plus tard, une cliente écrit qu'elle n'a pas pu payer, parce que le formulaire de carte bancaire est inaccessible au clavier. Les deux sont vrais. Le contrôle automatique était réussi, et le site a pourtant laissé une vraie cliente en plan.

Ce guide montre comment tester sérieusement avec un petit budget : quels outils gratuits utiliser, une routine manuelle de 15 minutes, une première prise en main d'un lecteur d'écran, et quand payer un audit.

Un outil automatique peut-il me dire si mon site est accessible ?

Non. Les outils automatiques trouvent vite certains problèmes, mais beaucoup de questions d'accessibilité demandent une réponse humaine. Quand le Government Digital Service britannique a testé 10 outils sur une page comportant 143 défauts connus, le meilleur en a trouvé 41 %. Le W3C le dit clairement : les outils d'évaluation « ne peuvent pas déterminer l'accessibilité, ils peuvent seulement y aider ».

Le test du GDS (s'ouvre dans un nouvel onglet) date de février 2017, et ses 41 % (obtenus par Asqatasun) incluaient les invitations de l'outil à des vérifications manuelles. Les outils ont progressé depuis, mais l'écart a toujours la même cause. Un logiciel peut voir qu'une image n'a pas de texte alternatif. Il ne peut pas voir que « robe rouge » décrit mal la photo d'un costume bleu, ni si l'ordre de tabulation est logique.

Considérez donc un outil de vérification comme un détecteur de fumée, pas comme une expertise du bâtiment. Il vaut quand même la peine de le lancer : le WebAIM Million 2026 (s'ouvre dans un nouvel onglet) a trouvé des erreurs détectables sur 95,9 % des pages d'accueil du premier million de sites, la plupart des sites ont donc des défauts simples à corriger sans attendre. Comme le dit le guide du W3C pour choisir ses outils (s'ouvre dans un nouvel onglet) : « Le jugement humain est nécessaire. »

Quels outils gratuits de test d'accessibilité utiliser ?

Utilisez un ou deux outils automatiques, un vérificateur de contraste et un lecteur d'écran. Les outils appliquent des règles différentes et présentent leurs résultats différemment : deux outils en trouvent généralement plus qu'un seul. Chaque outil ci-dessous a une version gratuite. Vérifiez les conditions actuelles de chacun avant de vous y fier, car les noms, les fonctions et les tarifs changent.

Que puis-je vérifier manuellement en 15 minutes ?

Pas mal de choses. Les Easy Checks (s'ouvre dans un nouvel onglet) du W3C portent sur les titres de page, les textes alternatifs, les titres de section, le contraste, les liens d'évitement, la visibilité du focus clavier, la langue de la page, le zoom, les sous-titres et les étiquettes de formulaire. Choisissez une page importante, comme une fiche produit ou votre formulaire de réservation, et consacrez une ou deux minutes à chaque vérification. Vous trouverez des choses qu'aucun outil ne signale.

Le W3C précise que ces vérifications « ne couvrent que quelques problèmes d'accessibilité » : ce n'est donc pas une évaluation complète. C'est tout de même le quart d'heure le plus rentable que vous puissiez y consacrer :

1. Titre de la page (1 minute). L'onglet du navigateur dit-il ce qu'est la page, par exemple « Réserver une table | Chez Rosa », plutôt que « Accueil » partout ?
2. Images (2 minutes). Affichez les textes alternatifs avec WAVE ou un outil équivalent. Sont-ils exacts ? Les images décoratives sont-elles ignorées ?
3. Titres (2 minutes). Listez les titres et lisez-les seuls. Fonctionnent-ils comme une table des matières ?
4. Contraste (2 minutes). Vérifiez le texte courant, le petit texte gris, le texte des boutons et le texte sur image.
5. Clavier (4 minutes). Mettez la souris de côté et parcourez la page avec Tab (voir la section suivante).
6. Zoom (2 minutes). À 200 %, puis à 400 %, pouvez-vous encore tout lire et utiliser le menu sans défiler horizontalement ?
7. Formulaires et langue (2 minutes). Cliquez sur l'étiquette de chaque champ ; dans un formulaire bien conçu, le curseur se place dans le champ. Vérifiez dans le rapport de l'outil si la langue de la page manque.

Comment tester au clavier ?

Rangez la souris. Appuyez sur Tab pour avancer, Maj+Tab pour revenir en arrière, Entrée pour suivre les liens, Espace ou Entrée pour activer les boutons, et les flèches dans les menus et les boutons radio. Chaque élément interactif doit être atteignable, vous devez toujours voir où vous êtes, et vous ne devez jamais rester bloqué.

Sur Mac, Safari saute les liens quand vous appuyez sur Tab, tant que vous n'avez pas activé dans ses réglages avancés l'option qui permet à la touche Tab de mettre en évidence chaque élément d'une page web. Vérifiez ensuite :

• Voyez-vous toujours où vous êtes ? Si le contour du focus disparaît, l'utilisateur du clavier est perdu.
• L'ordre est-il logique ? Le focus doit suivre l'ordre de lecture.
• Quelque chose est-il masqué ? Un en-tête fixe ou un bandeau cookies qui cache l'élément ayant le focus ne respecte pas le critère Focus non masqué des WCAG 2.2.
• Pouvez-vous ressortir ? Ouvrez chaque menu, pop-up et sélecteur de date, puis essayez d'en sortir. La touche Échap doit fermer les boîtes de dialogue.
• Le parcours complet fonctionne-t-il ? Ajoutez un produit, modifiez la quantité, appliquez un code promo et allez jusqu'au paiement sans souris.

Notez chaque défaut avec précision : « Le sélecteur de taille de la fiche produit ne s'ouvre ni avec Entrée ni avec Espace » sera corrigé bien plus vite que « le clavier ne marche pas ».

Comment tester avec un lecteur d'écran pour la première fois ?

Commencez avec le lecteur d'écran déjà présent sur votre appareil, ou NVDA sous Windows, et écoutez une page. Le but n'est pas de vous en servir comme un expert. Vous vérifiez que les titres, liens, boutons, images et champs de formulaire sont annoncés avec des noms qui ont du sens, et que rien d'important ne reste muet.

• Mac : Commande+F5 active et désactive VoiceOver ; Contrôle+Option+U ouvre le rotor, une liste des titres, liens et éléments de formulaire.
• Windows : dans NVDA, appuyez sur H pour passer d'un titre à l'autre et sur Insert+F7 pour lister les liens et les titres.
• Téléphone : activez VoiceOver (iPhone) ou TalkBack (Android) et balayez vers la droite pour passer d'un élément à l'autre. Apprenez d'abord à le désactiver.

Concentrez-vous sur l'essentiel. Dans l'enquête 2024 de WebAIM auprès des utilisateurs de lecteurs d'écran (s'ouvre dans un nouvel onglet), 71,6 % des répondants disent parcourir d'abord une longue page par ses titres : commencez donc par là. Affichez ensuite la liste des liens : cinq liens « En savoir plus » n'apprennent rien à personne. « Ajouter au panier, pull bleu marine » est un bouton utile ; « bouton » ne l'est pas. Enfin, remplissez un formulaire et vérifiez que chaque champ et chaque erreur sont lus.

Restez modeste dans vos conclusions. Si quelque chose vous paraît défaillant, c'est probablement le cas ; si tout vous paraît correct, ce n'est pas une preuve. Pour savoir comment travaillent les utilisateurs expérimentés, lisez comment les personnes handicapées utilisent le web.

Comment vérifier le zoom, la redistribution et l'espacement du texte ?

Zoomez à 200 % dans le navigateur et vérifiez que le texte s'agrandit sans être coupé ni se chevaucher. Testez ensuite la redistribution : avec un zoom à 400 % dans une fenêtre de 1 280 pixels de large, le contenu doit tenir sans défilement horizontal. Enfin, augmentez l'espacement entre les lettres, les mots, les lignes et les paragraphes, et vérifiez que rien ne se casse ni ne disparaît.

Ces vérifications correspondent aux critères WCAG Redimensionnement du texte (1.4.4), Redistribution (1.4.10) (s'ouvre dans un nouvel onglet) et Espacement du texte (1.4.12) (s'ouvre dans un nouvel onglet). La redistribution se mesure sur une largeur de 320 pixels CSS, qui, selon les WCAG, « équivaut à une largeur initiale d'espace de restitution de 1280 pixels CSS avec un zoom de 400 % ». L'espacement du texte exige que rien ne se perde quand un lecteur règle l'interligne à 1,5 fois la taille de la police, l'espacement des paragraphes à 2 fois, celui des lettres à 0,12 fois et celui des mots à 0,16 fois.

Un bookmarklet d'espacement du texte, un petit script enregistré comme favori, applique les quatre valeurs en un clic. Cherchez le texte qui déborde des boutons et les libellés coupés sur les bords. À 400 % de zoom, un ordinateur portable affiche à peu près ce qu'affiche un petit téléphone : un site responsive bien conçu passe donc déjà une bonne partie de ces tests.

Comment vérifier les formulaires, les erreurs et le paiement ?

Remplissez chaque formulaire important trois fois : une fois correctement, une fois en laissant tous les champs vides, et une fois avec des erreurs volontaires. Chaque champ doit avoir une étiquette visible, chaque erreur doit être expliquée en toutes lettres à côté de son champ, et vous devez pouvoir coller du texte dans les champs de mot de passe et de code de vérification.

• Erreurs. « Saisie non valide » en rouge ne suffit pas. « Saisissez la date d'expiration au format MM/AA », à côté du champ, oui. Après l'envoi, le focus doit se placer sur le récapitulatif des erreurs ou sur le premier champ en erreur.
• Connexions et codes. Selon le critère d'authentification accessible (s'ouvre dans un nouvel onglet) des WCAG 2.2, bloquer le collage ou les gestionnaires de mots de passe est un échec, sauf s'il existe un autre moyen de se connecter.
• CAPTCHA et délais. Dans l'enquête de WebAIM, les utilisateurs de lecteurs d'écran classent le CAPTCHA comme l'élément le plus problématique du web. Vérifiez qu'il existe une alternative accessible et que les délais peuvent être prolongés.

Notre check-list d'accessibilité web propose une liste plus complète pour les boutiques, bandeaux cookies et pop-up compris.

Que comprend un audit d'accessibilité professionnel, et quand en faut-il un ?

Un audit d'accessibilité est une évaluation structurée, menée par un spécialiste, au regard d'une norme précise, en général les WCAG 2.1 ou 2.2 niveau AA. Il combine des analyses automatiques avec des tests manuels et avec des technologies d'assistance sur vos gabarits et parcours clés, et se conclut par un rapport hiérarchisé. Il vous en faut un quand la loi s'applique à vous, avant un lancement important, ou quand des clients demandent des preuves.

Avant de valider un devis, demandez :

• Selon quelle norme, quelle version et quel niveau testerez-vous (les WCAG, ou en France le RGAA pour le secteur public) ?
• Quels gabarits et parcours sont inclus ? Pour une boutique : accueil, catégorie, fiche produit, panier, paiement, pages du compte et formulaires.
• Testez-vous manuellement avec des lecteurs d'écran, le clavier et le zoom, et sur quels navigateurs et appareils ?
• Le rapport classe-t-il les problèmes par gravité, les localise-t-il et propose-t-il des corrections ?
• Un nouveau test après corrections est-il inclus ?

Les prix varient beaucoup selon le prestataire, le pays et le périmètre : comparez ce qui est inclus. Si l'European Accessibility Act vous concerne, un audit étaye aussi les informations que vous publiez ; notre guide de l'EAA explique qui est concerné.

Pourquoi tester avec des utilisateurs handicapés ?

Parce que respecter une norme et être facile à utiliser, ce n'est pas la même chose. Un tunnel de commande peut satisfaire tous les critères WCAG et demander tout de même vingt minutes à un utilisateur de lecteur d'écran. Le W3C indique qu'évaluer avec des utilisateurs handicapés « révèle des problèmes d'utilisabilité que l'évaluation de la conformité seule ne découvre pas », et cela montre à votre équipe comment les gens utilisent vraiment le site.

Pas besoin de laboratoire. Une poignée de sessions sur votre tâche la plus importante, comme trouver un produit et payer, vous en apprendra plus qu'une nouvelle série d'analyses. Recrutez par l'intermédiaire d'associations de personnes handicapées, d'agences d'études ou parmi vos propres clients, et rémunérez les participants pour leur temps. Laissez-les utiliser leurs propres appareils et réglages. Le guide du W3C pour impliquer les utilisateurs dans l'évaluation (s'ouvre dans un nouvel onglet) en détaille les aspects pratiques.

Que faire des résultats ?

Classez les problèmes selon la gravité du blocage et l'endroit où ils se produisent, corrigez-les dans le code et les contenus du site, testez de nouveau et consignez ce qui reste à faire. Un champ sans étiquette dans le tunnel de commande compte davantage qu'un contraste un peu faible dans le pied de page, et une correction dans un gabarit commun répare toutes les pages qui l'utilisent.

1. Hiérarchisez. D'abord les blocages sur les parcours clés (paiement, réservation, inscription), puis les gabarits communs, puis les pages isolées.
2. Corrigez à la source. Modifiez le thème, le composant ou le contenu, pas seulement le symptôme.
3. Testez de nouveau. Refaites les mêmes vérifications, manuellement comme avec les outils.
4. Documentez. Listez les problèmes connus, datés, dans votre déclaration d'accessibilité. Notre guide des WCAG 2.2 explique les critères les plus récents.
5. Recommencez. Ajoutez une vérification au clavier et une analyse automatique à chaque mise en production.

Si vous utilisez un widget d'accessibilité, le nôtre compris, testez avec le widget fermé. Un panneau comme SiteAccessible offre aux visiteurs des moyens supplémentaires d'adapter la page, mais les WCAG évaluent si la page fonctionne dans son état par défaut. Certains dispositifs d'audit n'évaluent pas les pages qui exécutent un script d'overlay : renseignez-vous d'abord auprès de votre auditeur.