Vérifier l’accessibilité d’un site web revient à mesurer un écart entre ce que perçoit un utilisateur valide et ce que perçoit une personne naviguant avec un lecteur d’écran, un clavier seul ou un afficheur braille. Le RGAA 4.1.2, référentiel français de référence, structure la vérification autour de critères couvrant l’ensemble des composants d’une page. L’European Accessibility Act, texte européen distinct, élargit le périmètre des sites concernés, même si les microentreprises bénéficient d’exemptions dans plusieurs cas.
Tests automatisés et contrôles manuels : ce que chaque méthode détecte
La distinction entre vérification automatique et contrôle manuel structure toute démarche d’audit. Confondre les deux conduit soit à un faux sentiment de conformité, soit à un budget d’audit disproportionné.
Lire également : Qu'est-ce qu'une API avec un exemple ?
| Critère | Test automatisé | Contrôle manuel |
|---|---|---|
| Type de défauts détectés | Erreurs vérifiables par règle (attribut alt manquant, ratio de contraste insuffisant, balises ARIA mal formées) | Problèmes de contexte, de compréhension, de cohérence de navigation ou de parcours réel avec technologie d’assistance |
| Couverture estimée du RGAA | Seule une partie minoritaire des critères peut être testée de façon fiable par un outil seul | Couvre les critères restants, notamment ceux liés à la pertinence du contenu alternatif |
| Temps de mise en œuvre | Quelques minutes par page | Plusieurs heures pour un échantillon représentatif |
| Compétences requises | Faibles (lancer un scan, lire un rapport) | Connaissance du RGAA, pratique d’un lecteur d’écran (NVDA, JAWS, VoiceOver) |
| Risque principal | Faux positifs fréquents, faux négatifs sur les critères contextuels | Dépend de l’expertise de l’auditeur, reproductibilité variable |
Un audit automatisé ne suffit pas pour conclure qu’un site est accessible. Les outils détectent les erreurs de code, pas les erreurs de sens. Un texte alternatif présent mais non pertinent (« image.jpg ») passera le test automatique sans problème.

A découvrir également : Qu'est-ce qui est accessible numériquement ?
Échantillon de pages et périmètre d’audit RGAA
Auditer la totalité d’un site de plusieurs centaines de pages n’est ni réaliste ni demandé par le référentiel. La conformité se mesure sur un échantillon représentatif, pas sur toutes les pages. Le choix de cet échantillon conditionne la fiabilité du résultat.
Une vérification sérieuse sélectionne des pages couvrant les différents modèles de contenu et parcours utilisateur :
- Page d’accueil, page de contact, page de mentions légales (pages obligatoires dans tout échantillon RGAA)
- Pages contenant des formulaires, un moteur de recherche interne, un processus d’authentification ou un tunnel d’achat
- Pages intégrant des contenus multimédias (vidéo, audio, documents PDF téléchargeables)
- Au moins une page par gabarit distinct utilisé sur le site (article de blog, fiche produit, page catégorie)
Cette méthode présente une limite : un défaut présent sur une page non incluse dans l’échantillon échappera à l’audit. Documenter les critères de sélection dans la déclaration d’accessibilité permet de tracer le périmètre réellement couvert.
RGAA et European Accessibility Act : deux cadres à ne pas confondre
Le RGAA et l’European Accessibility Act ne constituent pas une seule et même obligation. Le RGAA 4.1.2 est la méthode française de vérification, applicable aux services publics et à certains opérateurs privés délégataires. L’European Accessibility Act, transposée progressivement dans le droit des États membres, vise les produits et services numériques du secteur privé (e-commerce, banque en ligne, transport).
En pratique, un site de e-commerce français pourrait être soumis aux deux textes simultanément. Le RGAA s’appuie sur les WCAG du W3C, niveau AA. L’European Accessibility Act renvoie elle aussi aux WCAG, mais ses exigences portent davantage sur le résultat fonctionnel que sur le respect critère par critère d’un référentiel technique.
Pour un éditeur de site, la question à trancher est donc : quel texte s’applique à mon activité, et quel référentiel technique utiliser pour démontrer la conformité ? Vérifier l’accessibilité sans identifier le cadre juridique applicable rend l’audit difficilement exploitable.
Déclaration d’accessibilité : une obligation souvent négligée
La conformité au RGAA impose la publication d’une déclaration d’accessibilité sur le site. Ce document mentionne le niveau de conformité atteint (totale, partielle ou non-conformité), la date de l’audit, les dérogations éventuelles et un moyen de contact pour signaler un défaut.
Nombre de sites affichent une déclaration datée de plusieurs années ou rédigée avant une refonte majeure. Une déclaration obsolète équivaut juridiquement à une absence de déclaration.

Combiner outils de scan et navigation assistive pour un diagnostic fiable
Lighthouse, intégré aux outils de développement de Chrome, attribue un score d’accessibilité pondéré. Wave, édité par WebAIM, superpose directement sur la page les alertes et erreurs détectées, ce qui facilite la localisation visuelle des problèmes. Ara, outil mis à disposition par l’administration française, est spécifiquement conçu pour un audit RGAA critère par critère.
Aucun de ces outils ne remplace un test de navigation réelle avec un lecteur d’écran. Parcourir un formulaire de contact avec NVDA sous Windows ou VoiceOver sous macOS révèle des blocages qu’aucun scan automatique ne signale : un ordre de tabulation incohérent, un message d’erreur non vocalisé, un bouton dont le libellé accessible ne correspond pas à sa fonction visuelle.
La séquence la plus efficace commence par un scan automatique pour éliminer les erreurs de code évidentes, puis passe à une navigation clavier complète sur l’échantillon retenu, et termine par des tests avec au moins un lecteur d’écran. Chaque étape filtre une catégorie de défauts différente.
Un score Lighthouse de 100 ne garantit pas la conformité RGAA. Il signifie que les critères testables automatiquement par cet outil sont respectés, ce qui représente une fraction du référentiel. Publier ce score comme preuve d’accessibilité expose à des contestations fondées dès qu’un utilisateur de technologie d’assistance rencontre un obstacle non couvert par le scan.

