Un client m'appelle un mardi matin, un peu paniqué. Il a reçu une mise en demeure : son site doit être accessible avant la fin du trimestre, sinon l'amende tombe. Je lui demande s'il a déjà fait auditer la chose. Réponse : « J'ai passé un outil automatique, il me met 92 sur 100, donc je suis bon, non ? »
Spoiler : non. Un score automatique de 92 ne vous dit rien de votre conformité réelle. Ce chiffre mesure ce qu'une machine sait vérifier, et une machine ne sait pas grand-chose. Pour auditer l'accessibilité d'un site web correctement, il faut accepter une vérité désagréable : les outils automatiques ne détectent qu'une partie des problèmes, et jamais les plus subtils.
Je vais vous montrer la méthode que j'utilise concrètement, celle qui tient devant un avocat ou un organisme de contrôle. Pas la version marketing des prestataires, la version opérationnelle.
Points clés à retenir
- Un audit sérieux s'appuie sur le RGAA (référentiel français) ou les WCAG, jamais sur un score d'outil.
- La règle de l'échantillon impose de tester un nombre précis de pages, pas « quelques pages au hasard ».
- Certains critères ne sont jamais vérifiables automatiquement : alternatives textuelles pertinentes, ordre de lecture, pertinence des intitulés.
- Le rapport d'audit doit lister les non-conformités avec leur gravité, page par page.
- Un audit sans utilisateur en situation de handicap laisse passer 20 à 30 % des blocages réels selon mon expérience.
Comment auditer l'accessibilité d'un site web sans se raconter d'histoires
Le piège classique : ouvrir un scanner en ligne, voir du vert, et considérer le dossier clos. J'ai fait cette erreur sur un projet e-commerce il y a quelques années. L'outil me sortait un sans-faute sur les formulaires. Un test manuel au clavier a révélé que le champ de recherche était inaccessible : impossible d'y accéder au Tab. Le scanner ne l'avait pas vu parce qu'il ne simule pas la navigation.
Auditer, c'est un processus en entonnoir. On commence large (périmètre), on resserre (échantillon), on automatise ce qui peut l'être, puis on passe du temps là où ça compte : les tests manuels.
Étape 1 : définir le périmètre avant de toucher au clavier
Un audit mal cadré est un audit inutile. Il faut lister les sites ou applications concernés, préciser s'il s'agit d'un intranet ou d'un site public, et décider si le périmètre inclut les déclarations d'accessibilité et les contenus tiers (vidéos intégrées, widgets, cartes interactives).
Sur un site que j'ai repris l'an dernier, 40 % des non-conformités venaient en fait d'un module de réservation sous-traité. Le périmètre officiel ne le mentionnait pas — donc personne ne l'avait testé. Le contrôle, lui, ne s'en souciait pas : le module était bien affiché sur le site.
Étape 2 : constituer l'échantillon selon les règles du RGAA
C'est le point que la plupart des articles survolent. Le RGAA ne dit pas « testez quelques pages ». Il impose une règle de sélection précise : pour un site, l'échantillon doit contenir au minimum l'accueil, les mentions légales, la page de contact, le plan du site, la page d'aide, une page d'un formulaire (avec validation), une page d'authentification si elle existe, l'écran de déclaration d'accessibilité, et les pages correspondant à un document en téléchargement. Si le site propose plusieurs gabarits distincts, on ajoute au moins une page de chaque gabarit.
Concrètement, sur un site vitrine classique, ça donne une dizaine de pages. Sur un site marchand, on dépasse facilement la vingtaine. Vous devez documenter cette liste dans le rapport, sinon l'audit est attaquable.
Test accessibilité site web gratuit : ce que vous pouvez vraiment faire vous-même
Vous n'avez pas besoin d'un budget pour commencer. La moitié du travail peut se faire à coût nul, à condition de savoir ce que vous cherchez. Voilà l'ordre que je recommande.
Les tests manuels qui ne coûtent rien
Avant tout outil :
- Navigation clavier pure : Tab, Tab, Tab du haut jusqu'en bas. Vous devez voir où vous êtes à chaque instant. Un focus invisible = non-conformité.
- Zoom à 200 % dans le navigateur. Le contenu doit rester lisible, rien ne doit se chevaucher ni disparaître.
- Désactivation CSS pour vérifier l'ordre du contenu brut.
- Lecteur d'écran (NVDA sous Windows, VoiceOver sur Mac, gratuits tous les deux) : lancez-le vingt minutes sur votre page d'accueil. Ça fait très mal, en général.
- Contrastes : mesurez chaque paire texte/fond avec un outil type Color Contrast Analyser. Seuil WCAG AA : 4.5:1 pour le texte courant, 3:1 pour le grand texte.
Les contrastes, justement, méritent qu'on s'y arrête. Un outil comme WebAIM Contrast Checker vous sort le ratio en deux clics. J'ai vu des chartes graphiques entières s'effondrer face à ce test : le gris clair sur fond blanc « élégant » de la direction marketing est simplement invisible pour une personne malvoyante.
Les outils automatiques : un pré-audit, pas un audit
Rien contre eux, ils font gagner du temps. Mais gardez les proportions en tête : selon les critères du RGAA, une part importante des exigences n'est pas vérifiable par une machine. Un outil ne peut pas juger si une alternative textuelle est pertinente, ni si l'intitulé d'un lien est clair hors contexte, ni si l'ordre de lecture logique des blocs correspond à l'ordre visuel.
| Ce que l'outil automatique détecte bien | Ce qu'il ne peut pas juger |
|---|---|
| Attribut alt absent | Pertinence de l'alt quand il existe |
| Contraste insuffisant | Lisibilité réelle en situation de basse vision |
| Balises de titre mal imbriquées | Pertinence sémantique du titre |
| Langue du document non déclarée | Cohérence du contenu dans cette langue |
| Champ de formulaire sans label | Clarté du libellé pour l'utilisateur |
Audit RGAA : c'est quoi exactement, et pourquoi c'est opposable ?
Le RGAA — Référentiel général d'amélioration de l'accessibilité — est le cadre légal français. Il traduit les WCAG internationales en un ensemble de critères concrets, numérotés, testables. Chaque critère a une méthode de test officielle : soit automatique, soit manuelle, parfois les deux.
Ce qui le rend opposable, c'est justement sa granularité. Un audit RGAA ne dit pas « votre site est globalement accessible ». Il dit : « Critère 1.1 : pourcentage de conformité X, liste des pages où il échoue, description de chaque anomalie. » C'est ce niveau de détail qui permet à un organisme de contrôle de vérifier vos affirmations.
Enfin, une nuance : audit RGAA et attestation de conformité ne sont pas la même chose. L'audit établit les faits. L'attestation engage la responsabilité de l'entité qui la publie. On publie une attestation après avoir mené l'audit, jamais l'inverse.
Un audit RGAA automatique, ça existe ?
La question revient souvent, et la réponse est nette : non, pas un vrai audit. Il existe des outils de pré-audit qui pointent les critères testables en machine. Mais un audit RGAA complet implique la vérification de critères qui exigent une évaluation humaine. Un audit « 100 % automatique » ne peut, par construction, en couvrir qu'une fraction.
Audit accessibilité ERP : le cas particulier des logiciels
Pour une application métier, un ERP, un logiciel de gestion, la démarche change. Un ERP n'a pas de « pages » au sens classique : il a des écrans, des modales, des grilles de données interactives, des raccourcis clavier. L'échantillon RGAA s'applique différemment — on liste les écrans par fonctionnalité critique plutôt que par type de page.
J'ai conduit un audit sur un outil RH utilisé par 300 salariés dont une vingtaine en situation de handicap. Les blocages n'étaient pas là où on les attendait : pas sur les formulaires, mais sur les tableaux de suivi avec défilement horizontal sans indication, et sur les menus contextuels non atteignables au clavier. Le côté logiciel complexifie l'accessibilité parce que les composants sont souvent développés en interne, sans les réflexes HTML natif.
Tests couleur et tests utilisateurs : le niveau au-dessus
Le test couleur seul ne suffit pas. Une interface peut passer tous les contrastes et rester illisible pour un daltonien, si l'information est portée uniquement par la couleur (un point rouge « urgente », un vert « validé »). Il faut tester en simulant les différents types de daltonisme — les outils de simulation d'écran le permettent.
Et puis il y a l'étape que trop d'audits sautent : tester avec de vraies personnes en situation de handicap. Un utilisateur au lecteur d'écran depuis dix ans vous trouvera des blocages qu'aucun expert voyant n'aurait soupçonnés. Chez un client, un test avec trois utilisateurs a révélé qu'un menu de navigation, parfaitement conforme techniquement, portait des intitulés tellement abstraits que même le lecteur d'écran ne permettait pas de s'orienter. Un critère de pertinence — invisible aux outils.
À quoi ressemble un rapport d'audit utile
Un bon livrable contient : la liste des pages testées (l'échantillon documenté), le taux de conformité par critère, la description de chaque non-conformité avec la page concernée et la gravité, et un plan de correction hiérarchisé. Le classement par gravité est essentiel : vous ne corrigerez pas tout en même temps, il faut commencer par ce qui bloque l'accès.
Bref, si vous ne deviez retenir qu'une chose de cet article : l'audit d'accessibilité n'est pas une case à cocher dans un outil. C'est un travail d'expertise, avec des étapes documentées, des tests manuels et des utilisateurs. Le score automatique à 92 de mon client ? Le vrai chiffre, après audit sérieux, était en dessous de la moitié. Il a eu trois mois pour se mettre en règle. Il lui en a fallu presque cinq.
