Les meilleurs outils pour tester l’accessibilité de votre site web

Les outils de test accessibilité site web aident à repérer rapidement des problèmes comme un contraste insuffisant, un texte alternatif manquant ou un champ de formulaire mal identifié. Ils sont utiles pour démarrer, mais aucun scan automatique ne peut, à lui seul, confirmer que tout un site est accessible.

Key takeaways

• Choisissez l’outil selon votre objectif : diagnostic rapide, contrôle pendant le développement ou préparation d’un audit.
• Testez plusieurs pages et les parcours importants, pas seulement la page d’accueil.
• Complétez chaque scan par des vérifications au clavier et, si possible, avec un lecteur d’écran.
• Transformez les résultats en tâches précises, attribuées et classées par priorité.
• WCAG, RGAA et EN 301 549 sont liés, mais ne désignent pas le même référentiel.

Pourquoi utiliser des outils de test accessibilité site web ?

Un outil d’évaluation peut faire ressortir des défauts visibles dans le code ou la structure d’une page. Selon l’outil et le contexte, il peut notamment signaler des contrastes insuffisants, des textes alternatifs absents, des libellés de formulaire manquants ou des problèmes de structure. Ces alertes donnent des pistes concrètes à vérifier et à corriger.

Pour une petite entreprise, l’intérêt est pratique : vous pouvez repérer des problèmes récurrents avant une refonte, après une mise à jour ou pendant la création d’une nouvelle page. Pour une agence, un premier scan fournit aussi une base pour discuter des corrections avec un client ou une équipe de développement.

Mais un résultat automatisé n’est pas un verdict. Le W3C rappelle que les outils peuvent aider à repérer des problèmes sans déterminer seuls si un site est accessible. Certains contrôles exigent un jugement humain : par exemple, un texte alternatif peut exister tout en décrivant mal l’image, et un parcours peut être techniquement navigable sans être compréhensible.

Il faut également séparer trois objectifs : repérer des défauts, évaluer un site au regard d’un référentiel et déterminer les obligations applicables à une organisation. Un scanner sert surtout au premier objectif et peut contribuer au second. Il ne remplace pas une évaluation complète ni un avis juridique sur votre situation.

Quels outils choisir : WAVE, axe, Lighthouse ou ARA ?

Il n’existe pas un outil unique qui répond à tous les besoins. Certains sont pratiques pour une vérification rapide d’une page, d’autres s’intègrent à un travail de développement ou orientent un audit selon des critères. La sélection ci-dessous aide à choisir un point de départ, pas un classement absolu.

Outil ou famille	À privilégier pour	À garder en tête
WAVE	Examiner une page et comprendre visuellement les alertes affichées	Une alerte doit être vérifiée dans son contexte ; un résultat sans alerte ne prouve pas l’accessibilité
axe DevTools	Repérer des problèmes pendant le travail de développement	Les contrôles automatiques ne couvrent pas tous les critères nécessitant un jugement humain
Lighthouse	Ajouter une vérification rapide à un contrôle technique d’une page	Ne le traitez pas comme un audit complet du site
ARA et les outils guidés RGAA	Préparer une évaluation structurée en contexte français	Suivez le périmètre et la méthode de l’outil choisi

Pour comparer deux outils, lancez-les sur la même page et examinez les constats, pas seulement un score. Demandez-vous si le résultat explique où se trouve le problème, quel élément est concerné et quelle vérification manuelle doit suivre. Un outil utile permet de passer de l’alerte à une action compréhensible.

En France, le portail public Tests et audits d’accessibilité présente un parcours d’audit rapide portant sur 25 critères essentiels, tandis que le RGAA comporte 106 critères. Le même portail propose des ressources pour comprendre les critères et le déroulement d’un audit. Ces repères ne signifient pas qu’un outil qui vérifie une partie des critères couvre automatiquement l’ensemble du référentiel.

Un outil français récent, RGAA Scanner, indique s’appuyer sur axe-core, couvrir WCAG 2 niveaux A et AA et référencer le RGAA 4.1.2. Ce sont les caractéristiques déclarées par cet outil, pas une garantie que tous les scanners couvrent les mêmes points. Consultez sa présentation et son périmètre avant de l’utiliser pour un besoin précis.

Comment tester l’accessibilité d’un site étape par étape ?

Une méthode courte et répétable est souvent plus utile qu’un grand nombre de scans ponctuels. Gardez une trace des pages, des problèmes et des corrections pour pouvoir contrôler ensuite ce qui a changé.

1. Définissez le périmètre

Listez les pages et les parcours que vos visiteurs utilisent réellement. Incluez au minimum la page d’accueil, une page de service ou de produit, un formulaire important, les coordonnées et les pages qui comportent des composants interactifs. Si votre site contient un panier, un espace client ou une prise de rendez-vous, ajoutez ces parcours.

Un scan d’une seule URL ne décrit que cette page dans l’état où elle a été testée. Il ne vérifie pas automatiquement les autres modèles de page, les menus ouverts, les fenêtres modales ou les étapes d’un formulaire. Pour contrôler l’ensemble du site, il faut définir un échantillon représentatif ou un périmètre plus large.

2. Lancez un premier scan automatique

Utilisez un ou deux outils sur chaque type de page retenu. Notez l’URL, la date, l’outil et le problème signalé. Évitez d’additionner mécaniquement les alertes de plusieurs outils : une même cause peut produire plusieurs messages, et une alerte peut nécessiter une vérification avant d’être classée comme défaut réel.

3. Vérifiez les alertes dans la page

Cliquez sur l’élément concerné et observez son usage. Pour une image, demandez-vous si son alternative communique l’information utile ou si l’image est décorative. Pour un champ, vérifiez que son rôle et les instructions sont compréhensibles. Pour un contraste, examinez le texte et l’arrière-plan réellement affichés, y compris les états au survol ou au focus.

4. Testez sans souris

Parcourez la page avec le clavier : utilisez Tab pour avancer, Maj + Tab pour revenir et les touches usuelles pour activer les contrôles. Vérifiez que le focus est visible, que l’ordre de navigation est cohérent et que vous pouvez atteindre puis quitter les menus, boutons et fenêtres. Essayez d’effectuer les tâches essentielles sans utiliser la souris.

5. Faites un contrôle avec un lecteur d’écran

Un test de base avec un lecteur d’écran aide à entendre l’ordre et les noms annoncés pour les liens, boutons, titres et champs. Si cette vérification est nouvelle pour vous, commencez par un parcours simple et concentrez-vous sur une tâche : trouver une information, remplir un formulaire ou ouvrir le menu. Pour un contrôle approfondi, faites appel à des personnes qui utilisent ces technologies au quotidien.

6. Recommencez après les corrections

Une correction peut résoudre un problème sur un modèle de page et en créer un autre ailleurs. Relancez les tests sur les pages concernées, puis vérifiez le parcours au clavier et, si pertinent, avec le lecteur d’écran. Gardez une trace de ce qui a été corrigé et de ce qui reste à contrôler.

Que peut détecter un scan automatique — et que ne peut-il pas confirmer ?

Les scanners sont efficaces pour signaler certaines caractéristiques mesurables ou repérables dans le code. Ils peuvent notamment aider à trouver des textes alternatifs absents, des contrastes à examiner, des éléments sans nom accessible ou des problèmes liés à la structure. La détection dépend de l’outil, de la page et de la manière dont le contenu est construit.

En revanche, un outil ne comprend pas toujours l’intention. Il peut constater qu’une image possède un texte alternatif, mais pas décider si celui-ci est pertinent pour la tâche. Il ne juge pas non plus, à lui seul, si les instructions d’un formulaire sont claires, si un message d’erreur aide réellement à poursuivre ou si l’ordre de lecture a du sens.

Voici une règle simple : considérez un résultat automatique comme un indice à confirmer, et non comme une conclusion définitive. À l’inverse, l’absence d’alerte n’établit pas qu’une page est accessible. Associez les scans à des essais humains, en particulier sur les contenus et parcours importants.

Si vous préparez une évaluation plus large, le guide KlearKomply sur la checklist d’accessibilité EAA pour les petites entreprises peut aider à structurer les contrôles à prévoir. Utilisez-le comme point de départ pratique, puis adaptez le périmètre à votre site et à vos obligations.

WCAG, RGAA et EN 301 549 : quelle différence ?

Ces noms désignent des cadres liés à l’accessibilité numérique, mais ils ne sont pas interchangeables. Les WCAG sont des recommandations internationales du W3C. Le RGAA est le référentiel français qui s’appuie sur les WCAG et organise des critères et des tests. Pour vous familiariser avec son approche, le portail public français présente les critères du RGAA et les tests d’audit.

Dans l’Union européenne, la Commission indique que les exigences de la directive sur l’accessibilité du web s’appuient sur la norme harmonisée EN 301 549 v3.2.1. Cette norme couvre des produits et services liés aux technologies de l’information et de la communication, dont les sites web et applications mobiles. Les textes applicables et leur portée dépendent toutefois du type d’organisation et de service.

Attention à ne pas confondre la directive européenne sur l’accessibilité du web avec l’European Accessibility Act. La Commission les distingue et indique que la directive sur l’accessibilité du web concerne les sites et applications mobiles des organismes du secteur public. Une entreprise doit donc vérifier les règles pertinentes pour son activité et son pays, plutôt que de choisir un référentiel au seul vu du nom d’un outil.

En pratique, demandez-vous d’abord : quel référentiel dois-je utiliser, quel périmètre dois-je évaluer et qui peut confirmer les résultats ? Ensuite, choisissez un outil qui aide à documenter ce périmètre. L’outil ne détermine pas à lui seul quelle réglementation s’applique.

Comment prioriser les problèmes et transmettre les corrections ?

Un rapport qui accumule les alertes n’est pas encore un plan de travail. Pour qu’une équipe puisse agir, transformez chaque problème confirmé en tâche courte et localisée.

Pour chaque tâche, indiquez :

• La page et l’élément concernés : URL, composant et emplacement dans la page.
• Le problème observé : ce qui se passe avec la souris, le clavier ou le lecteur d’écran.
• La vérification effectuée : résultat du scan et contrôle humain réalisé.
• La correction attendue : formulation concrète, sans imposer une solution technique si plusieurs sont possibles.
• Le contrôle après correction : comment l’équipe saura que le problème est résolu.

Classez d’abord les défauts qui bloquent un parcours essentiel ou rendent une information importante inaccessible. Ensuite, traitez les problèmes qui se répètent sur plusieurs pages, car une correction au niveau d’un composant partagé peut éviter de reproduire le même défaut. Puis planifiez les améliorations moins bloquantes.

La Commission européenne recommande de corriger les problèmes à leur source et souligne l’importance de faire participer des personnes handicapées aux tests. En pratique, cela signifie qu’il vaut mieux corriger un composant ou un modèle de page réutilisé que masquer séparément la même alerte sur plusieurs URL, et recueillir des retours d’usage lorsque c’est possible.

Un exemple de tâche exploitable : « Sur la page de contact, le champ téléphone n’a pas de libellé annoncé. Ajouter un libellé associé au champ, puis vérifier son nom au clavier et avec un lecteur d’écran. » Cette consigne est plus actionnable que « corriger les formulaires » ou « améliorer l’accessibilité ».

Erreurs fréquentes et prochaine étape

Tester seulement la page d’accueil. Elle ne représente pas forcément les formulaires, pages de vente, menus ou éléments interactifs du reste du site. Choisissez plusieurs modèles de page et les parcours qui comptent pour votre activité.

Se fier uniquement à un score. Un score résume certains constats selon une méthode donnée. Il ne remplace pas la liste des problèmes confirmés, les tests manuels ni la vérification du référentiel visé.

Traiter chaque alerte comme un défaut certain. Examinez le contexte et confirmez le problème avant de créer une tâche. Cette étape réduit les faux positifs et évite de demander des corrections inadaptées.

Confondre scan et audit. Un scan de préparation peut accélérer le repérage, mais ne constitue pas, à lui seul, un audit complet ni une garantie de conformité. Le périmètre, la méthode et les contrôles humains doivent être adaptés au besoin.

Pour obtenir un premier aperçu, vous pouvez lancer le Quick Scan gratuit de KlearKomply sur votre site, puis examiner les problèmes signalés. Si vous souhaitez un contrôle plus large de préparation du site, le Full Readiness Scan à 29 € couvre jusqu’à 50 pages et peut aider à transformer les constats en priorités. Ces scans sont des outils de préparation : ils ne remplacent pas un audit complet ni un avis juridique. Pour une vue d’ensemble, consultez aussi le guide KlearKomply sur le scan d’accessibilité d’un site EAA.

La bonne démarche est simple : scannez plusieurs pages, vérifiez les constats manuellement, testez au clavier et classez les corrections par impact. Répétez ensuite les contrôles après chaque mise à jour importante. Un outil vous aide à démarrer et à suivre vos progrès ; l’accessibilité se construit dans la durée, avec des choix de conception et des tests adaptés aux personnes qui utilisent votre site.