Un score vert ne prouve pas qu’un site est accessible. Combinez outils automatiques et tests manuels (clavier, zoom, lecteur d’écran) selon une méthode alignée sur le RGAA.
Écrit par
Vous avez lancé un scan automatique, obtenu un score « vert », et… un utilisateur au clavier bloque encore sur le menu. Tester l’accessibilité d’un site, ce n’est pas lire un badge : c’est vérifier, concrètement, si le service reste utilisable pour tout le monde.
Si vous cherchez comment tester l’accessibilité d’un site web, ce guide vous donne une méthode claire : outils utiles, limites du 100 % automatique, contrôles manuels alignés sur le RGAA, et moment où un audit structuré devient nécessaire.
L’accessibilité web, c’est la capacité d’un site ou d’une application à être perçu, compris et utilisé par des personnes en situation de handicap — et, en pratique, par beaucoup d’autres (clavier, zoom, contrastes, conditions dégradées).
Tester sert à répondre à des questions précises :
En France, le RGAA (Référentiel général d’amélioration de l’accessibilité) fournit des critères et des tests pour structurer cette vérification. Sans méthode, on multiplie les correctifs isolés… et on rate les vrais blocages.
Un score Lighthouse ou un rapport WAVE peut être utile. Ce n’est pas une preuve de conformité RGAA. Beaucoup de critères exigent un jugement humain : pertinence d’une alternative textuelle, cohérence d’un parcours, compréhension d’un message d’erreur.
Tester, c’est :
Le RGAA 4.1.2 s’appuie notamment sur les niveaux A et AA des WCAG. Il organise des critères (images, couleurs, formulaires, navigation, scripts, etc.) avec des tests associés. Votre objectif de test : savoir quels critères passent / échouent sur vos pages clés, et pourquoi.
Voici les outils les plus courants pour un premier filet. Aucun ne remplace un contrôle manuel sérieux.
Ce qu’ils détectent bien : contrastes basiques, balises manquantes, certains rôles ARIA incorrects, attributs absents.
Ce qu’ils ratent souvent : qualité d’un alt, logique de parcours, modales mal gérées au clavier, contenus dynamiques, pertinence des intitulés de liens, compréhension réelle avec lecteur d’écran.
Utile pour prévenir les régressions. Pas suffisant pour prouver l’accessibilité d’un parcours métier.
Règle d’or : l’automatique ouvre le dossier, l’humain instruit.
Sélectionnez typiquement :
Documentez aussi la technologie (CMS, framework, composants UI) : beaucoup de problèmes viennent des composants réutilisés.
Sans souris :
Si un parcours critique échoue ici, le correctif est prioritaire — score automatique ou pas.
Testez zoom navigateur (jusqu’à 200 %) et largeurs étroites. Vérifiez que rien ne se coupe, ne se superpose, ni n’impose un scroll horizontal bloquant pour lire le contenu essentiel.
Selon l’OS :
Vous ne cherchez pas la perfection du premier coup. Vous vérifiez : titres annoncés, landmarks, labels de champs, boutons nommés, messages d’erreur perçus, états (ouvert/fermé, sélectionné).
Au lieu de « tout tester d’un coup », attaquez par thématiques à fort impact :
Notez pour chaque échec : page, critère, impact, capture / steps de reproduction.
Classez :
C’est cette liste — pas un score — qui doit alimenter le backlog.
Imaginez un formulaire Contact classique.
Automatique :
label explicite.Manuel clavier :
Lecteur d’écran :
Résultat : le scan donnait « plutôt bon ». Le parcours réel est cassé pour une partie des utilisateurs. C’est exactement pourquoi on combine les approches.
Exemple minimal de label correct :
<input type="email" placeholder="Votre email">
<label for="email">Adresse e-mail</label>
<input id="email" type="email" name="email" autocomplete="email">
Un bon score rassure l’équipe… et masque les trous. Traitez Lighthouse comme un smoke test, pas comme un audit.
Les problèmes vivent dans les tunnels, les filtres, les tableaux de données, les PDF, les espaces authentifiés.
On ajoute un aria-label, on casse autre chose. Chaque correctif majeur mérite un retest clavier + lecteur sur le scénario.
Sur un site vivant, visez d’abord la conformité substantielle des parcours critiques, documentée, avec un plan. La perfection permanente est un mythe opérationnel.
Un composant beau peut être inaccessible (icône sans nom accessible, tooltip souris-only, animation non interrupible).
Pour les équipes qui montent en compétence sur le front et les bonnes pratiques, une formation développement web aide à ancrer HTML sémantique, composants et culture qualité — le test devient alors plus simple, parce que le code de départ est meilleur.
Pour compléter, utilisez la méthode et les critères du RGAA et les WCAG du W3C. Pour la suite :
Il n’y en a pas un seul. Le duo le plus sain : un scanner (axe / WAVE / Lighthouse) + tests manuels (clavier, zoom, lecteur d’écran) guidés par le RGAA.
Oui pour démarrer : extensions gratuites, NVDA, VoiceOver, checklists WCAG/RGAA. La limite arrive sur la couverture, la méthode et la priorisation à l’échelle d’un produit réel.
Sur quelques pages clés, une demi-journée bien menée donne déjà une liste d’écarts actionnable. Un audit complet demande plus d’échantillon et de documentation.
Les bases (clavier, labels, contrastes, structure) se testent vite. Le RGAA devient indispensable dès que vous voulez des résultats comparables, opposables et complets.
Le test peut être ponctuel, partiel, exploratoire. L’audit est une évaluation structurée (méthode, échantillon, critères, restitution, plan). Quand le 100 % auto ne suffit plus, l’audit prend le relais.
Comment tester l’accessibilité d’un site web ? En combinant un filet automatique, des tests manuels sur les parcours critiques, et une grille de type RGAA pour ne rien laisser au hasard. Les outils accélèrent ; ils ne valident pas seuls. Les erreurs les plus coûteuses se voient au clavier et au lecteur d’écran, pas dans un score.
Prochaine étape concrète : choisissez 3 pages critiques, jouez le parcours au clavier, notez les bloqueurs, puis décidez si un simple backlog suffit… ou s’il vous faut un audit manuel structuré. Pour ce passage de l’auto au plan d’action, Yunt Audit est le relais naturel.