Tester l’accessibilité d’un site web ne consiste pas simplement à lancer un outil automatique et à corriger quelques erreurs de code. Une démarche d’accessibilité sérieuse combine tests automatisés, vérifications manuelles, analyse ergonomique et observation des usages afin d’identifier les obstacles réellement rencontrés par les utilisateurs.

En France, le RGAA (Référentiel général d’amélioration de l’accessibilité) constitue le cadre de référence pour évaluer l’accessibilité des services numériques concernés par les obligations réglementaires. Dans sa version actuellement en vigueur, le RGAA 4.1.2 propose 106 critères de contrôle, organisés autour de thématiques telles que les images, les couleurs, les formulaires, la navigation, les scripts ou encore la consultation.

Mais au-delà de la conformité à un référentiel, tester l’accessibilité d’un site revient surtout à répondre à une question essentielle :

Une personne, quelles que soient ses capacités et les technologies qu’elle utilise, peut-elle réellement comprendre le contenu et réaliser les actions proposées par le site ?

A Ludotic, nous abordons cette question à travers notre approche d’Ingénierie Humaine du Numérique, à la croisée de l’UX (Expérience Utilisateur), des Facteurs Humains et de l’ergonomie.

Pourquoi tester l’accessibilité d’un site web ?

Un site peut sembler parfaitement fonctionnel pour une personne qui utilise une souris, voit les couleurs, entend les contenus audio et comprend rapidement les conventions habituelles d’une interface. Pour d’autres utilisateurs, les mêmes choix de conception peuvent constituer des obstacles.

Un formulaire dont les champs ne sont pas correctement associés à leurs libellés, un bouton difficile à repérer au clavier, une information transmise uniquement par la couleur ou une fenêtre modale mal annoncée par un lecteur d’écran peuvent rendre une fonctionnalité difficile, voire impossible à utiliser.

L’accessibilité numérique vise notamment à rendre les contenus et services perceptibles, utilisables, compréhensibles et robustes, y compris avec des technologies d’assistance.

Tester l’accessibilité permet donc de :

• détecter les barrières qui empêchent ou compliquent certains usages ;
• vérifier la conformité à un référentiel comme le RGAA ;
• améliorer l’expérience utilisateur pour tous ;
• réduire les risques de régression lors des évolutions du site ;
• intégrer l’accessibilité dans la conception plutôt que de la traiter uniquement en fin de projet.

L’enjeu est donc à la fois technique, ergonomique et humain.

Quels sont les référentiels utilisés pour tester l’accessibilité ?

À l’échelle internationale, les WCAG (Web Content Accessibility Guidelines) du W3C constituent l’un des principaux standards de référence pour l’accessibilité des contenus web. Les WCAG 2.2 organisent les exigences autour de quatre grands principes : perceptible, utilisable, compréhensible et robuste.

En France, le RGAA fournit une méthode opérationnelle permettant de vérifier la conformité d’un service numérique à des critères d’accessibilité. Le RGAA 4.1.2 actuellement publié par la DINUM s’appuie sur les critères WCAG 2.1 de niveaux A et AA retenus dans la norme européenne de référence. La version 5 du RGAA est par ailleurs en cours de rédaction, avec une publication annoncée pour la fin de l’année 2026.

Il est donc important de distinguer deux notions :

• Tester l’accessibilité consiste à rechercher des barrières et à vérifier des critères précis.
• Évaluer la conformité consiste à appliquer une méthodologie définie, sur un périmètre et un échantillon de pages représentatifs, afin de déterminer le niveau de conformité du service.

Comment tester concrètement l’accessibilité d’un site web ?

Une évaluation pertinente repose sur plusieurs niveaux de tests complémentaires.

1. Commencer par définir le périmètre de test

Avant de tester un site, il faut déterminer quoi tester et dans quelles conditions.

Il n’est généralement pas nécessaire de vérifier chaque page individuellement. Dans le cadre d’un audit RGAA, l’évaluation porte sur un échantillon de pages représentatif du service.

Cet échantillon doit notamment prendre en compte :

• la page d’accueil ;
• les pages de contenu représentatives ;
• les pages comportant des formulaires ;
• les pages de recherche ou de résultats ;
• les parcours de connexion ou d’authentification ;
• les pages présentant des composants interactifs ;
• les pages comportant des tableaux, vidéos ou documents ;
• les différents modèles de pages utilisés sur le site.

Pour un site WordPress, il est également pertinent de tester les différents gabarits et composants réutilisables : menu, accordéon, carrousel, fenêtre modale, formulaire, système de recherche, navigation, etc.

L’objectif est de ne pas tester uniquement des pages isolées, mais de comprendre comment fonctionne le système dans son ensemble.

2. Utiliser des outils de test automatisé

Les outils automatisés constituent un excellent point de départ.

Ils peuvent notamment détecter rapidement :

• certaines images sans alternative textuelle ;
• des problèmes de contraste ;
• des éléments de formulaire mal structurés ;
• certains problèmes de hiérarchie HTML ;
• des attributs ARIA incorrects ou manquants ;
• certains problèmes liés aux liens ou aux boutons.

Des extensions de navigateur et outils spécialisés permettent de réaliser ce type d’analyse. Le W3C maintient notamment une liste d’outils d’évaluation de l’accessibilité.

Mais attention : un outil automatisé ne peut pas déterminer à lui seul si un site est accessible.

Le W3C rappelle qu’aucun outil ne permet de vérifier automatiquement l’ensemble de l’accessibilité d’un site et qu’une évaluation humaine reste nécessaire.

Par exemple, un outil peut détecter qu’une image possède un attribut alt. Il ne peut pas nécessairement déterminer si le texte alternatif décrit pertinemment l’information portée par l’image.

C’est toute la différence entre vérifier la présence d’un élément et évaluer sa pertinence pour l’utilisateur.

3. Tester le site au clavier

Le test au clavier est l’un des tests manuels les plus simples à réaliser et particulièrement révélateur.

Il consiste à naviguer sur le site sans utiliser la souris, principalement avec :

• Tab pour avancer ;
• Maj + Tab pour revenir en arrière ;
• Entrée pour activer un lien ou un bouton ;
• les touches fléchées lorsque le composant le prévoit ;
• Échap pour fermer certains composants.

On vérifie notamment :

• que tous les éléments interactifs sont accessibles ;
• que l’ordre de navigation est logique ;
• que le focus est toujours visible ;
• qu’aucun élément ne piège le clavier ;
• que les menus et composants interactifs peuvent être utilisés ;
• que les formulaires peuvent être complétés ;
• que les fenêtres modales peuvent être ouvertes et fermées.

Le W3C rappelle notamment que les sites accessibles doivent permettre l’accès au contenu et aux fonctionnalités au clavier, avec un focus visible et un ordre de navigation logique.

Ce test est particulièrement intéressant d’un point de vue ergonomique : il permet de comprendre comment l’interface se comporte lorsque l’utilisateur ne dispose plus du pointeur comme moyen principal d’interaction.

4. Vérifier la structure et la compréhension des contenus

L’accessibilité ne concerne pas uniquement les interactions.

La structure même de la page joue un rôle essentiel dans la compréhension et la navigation.

Il faut notamment vérifier :

• la présence et la pertinence du titre de page ;
• la hiérarchie des titres H1, H2, H3… ;
• la structuration des zones de navigation ;
• la pertinence des intitulés de liens ;
• la présence d’alternatives textuelles pertinentes ;
• la structure des listes et tableaux ;
• l’identification de la langue de la page ;
• la cohérence des contenus et des composants.

Par exemple, un lien intitulé simplement « Cliquez ici » peut être difficile à comprendre lorsque les liens sont parcourus indépendamment du reste de la page.

À l’inverse, un intitulé comme « Télécharger le rapport d’accessibilité » apporte immédiatement davantage d’information.

Cette dimension rejoint directement les principes d’ergonomie et d’UX : une interface accessible doit aussi permettre à l’utilisateur de comprendre où il se trouve, ce qu’il peut faire et ce qui va se passer lorsqu’il agit.

5. Tester les couleurs, les contrastes et la perception visuelle

Les choix graphiques peuvent également créer des barrières.

Il faut notamment vérifier :

• le contraste entre le texte et son arrière-plan ;
• la visibilité des éléments interactifs ;
• la visibilité du focus clavier ;
• l’utilisation de la couleur pour transmettre une information ;
• la lisibilité lorsque le texte est agrandi ;
• le comportement de l’interface lorsque certaines préférences d’affichage sont modifiées.

Un exemple classique consiste à utiliser uniquement une couleur pour signaler une erreur dans un formulaire.

Si un champ devient rouge mais qu’aucun message ou autre indication n’identifie l’erreur, l’information peut être perdue pour certaines personnes.

L’objectif n’est donc pas simplement de « respecter un ratio de contraste ». Il faut vérifier que l’information reste perceptible et compréhensible dans la situation réelle d’utilisation.

6. Tester les formulaires et les parcours

Les formulaires constituent souvent des points critiques en matière d’accessibilité.

Un formulaire accessible doit notamment permettre de comprendre :

• ce qui est demandé ;
• où saisir l’information ;
• quels champs sont obligatoires ;
• quelles erreurs ont été commises ;
• comment les corriger ;
• ce qui se passe après l’envoi.

Il faut donc tester le parcours complet, et pas seulement l’apparence du formulaire.

Par exemple :

Arriver sur le formulaire → identifier les champs → saisir les informations → provoquer une erreur → comprendre le message → corriger l’erreur → envoyer le formulaire → comprendre le résultat.

Cette approche par scénario est particulièrement importante dans une démarche d’Ingénierie Humaine du Numérique : l’accessibilité se mesure aussi à la capacité de l’utilisateur à atteindre son objectif sans obstacle inutile.

7. Tester avec des technologies d’assistance

Certains problèmes ne deviennent réellement visibles qu’en utilisant les technologies d’assistance concernées.

Il peut notamment être nécessaire de tester le site avec :

• un lecteur d’écran ;
• les fonctions d’agrandissement ;
• des outils de navigation clavier ;
• différentes configurations de navigateur et de système d’exploitation ;
• selon les besoins, des technologies d’assistance spécifiques.

Le RGAA prévoit d’ailleurs la définition d’un environnement de test, notamment lorsque certains critères nécessitent des vérifications avec des technologies d’assistance associées à des navigateurs et systèmes d’exploitation.

Ces tests permettent de vérifier ce que l’utilisateur perçoit réellement : intitulé d’un bouton, ordre de lecture, état d’un composant, message d’erreur, changement de contexte, etc.

8. Tester avec des personnes en situation de handicap

Un audit de conformité et un test utilisateur ne répondent pas exactement à la même question :

• Un audit permet de vérifier si des exigences techniques et fonctionnelles sont respectées.
• Un test utilisateur permet d’observer comment une personne réalise réellement une tâche avec le système.

Les deux approches sont donc complémentaires.

Le W3C recommande d’ailleurs de compléter les tests fonctionnels par des tests d’utilisabilité et indique que les personnes en situation de handicap peuvent être intégrées aux groupes de test.

A Ludotic, cette distinction est essentielle : une interface peut respecter de nombreux critères techniques tout en restant difficile à comprendre ou à utiliser dans certaines situations.

L’accessibilité ne doit donc pas être réduite à une checklist. Elle doit également être envisagée comme une question d’usage.

Pourquoi les tests automatisés ne suffisent-ils pas ?

C’est probablement l’une des idées les plus importantes à retenir. Un score obtenu avec un outil d’accessibilité ne constitue pas un audit d’accessibilité.

Les outils automatisés sont très utiles pour identifier rapidement certaines anomalies, mais ils ne peuvent pas apprécier toute la dimension sémantique, contextuelle et humaine d’une interface.

Selon le type de problème, leur capacité de détection varie :

Image sans alternative (alt)
→ Détection automatisée : oui, généralement.
→ Analyse humaine : nécessaire pour vérifier que l’alternative textuelle est pertinente et adaptée au contenu de l’image.

Contraste insuffisant
→ Détection automatisée : oui.
→ Analyse humaine : utile pour comprendre le contexte et vérifier que l’information reste réellement perceptible.

Bouton sans nom accessible
→ Détection automatisée : souvent.
→ Analyse humaine : nécessaire pour vérifier que le bouton est compréhensible et identifiable par l’utilisateur.

Hiérarchie des titres
→ Détection automatisée : partiellement.
→ Analyse humaine : nécessaire pour vérifier que la structure de la page est logique et facilite la compréhension.

Parcours au clavier
→ Détection automatisée : partiellement.
→ Analyse humaine : nécessaire pour vérifier que la navigation est réellement possible, cohérente et utilisable.

Message d’erreur
→ Détection automatisée : partiellement.
→ Analyse humaine : nécessaire pour vérifier que l’erreur est compréhensible et que l’utilisateur sait comment la corriger.

Pertinence d’un lien
→ Détection automatisée : non, ou très partiellement.
→ Analyse humaine : oui, pour vérifier que l’intitulé du lien permet de comprendre sa destination ou son action.

Compréhension d’un parcours
→ Détection automatisée : non.
→ Analyse humaine : oui, pour observer si l’utilisateur comprend les différentes étapes et sait comment atteindre son objectif.

Facilité d’utilisation
→ Détection automatisée : non.
→ Analyse humaine : oui, car l’utilisabilité dépend du contexte, des caractéristiques de l’utilisateur et de la situation d’usage.

Cette complémentarité est essentielle : les outils automatisés détectent certaines anomalies tandis que l’analyse humaine permet de comprendre leur impact réel sur l’expérience et les usages.

Une stratégie d’évaluation efficace combine donc automatisation, expertise et tests en situation.

Quelle méthode pour un audit d’accessibilité efficace ?

A Ludotic, nous recommandons une démarche en plusieurs étapes.

1. Comprendre le service

Avant de tester, il faut comprendre les objectifs du site, ses utilisateurs, ses fonctionnalités et ses parcours principaux.

2. Identifier les situations d’usage

Qui utilise le service ? Avec quelles capacités, contraintes, équipements ou technologies d’assistance ?

3. Définir un échantillon représentatif

Sélectionner les pages et fonctionnalités permettant de couvrir les principaux modèles, contenus et interactions.

4. Réaliser les tests automatisés

Utiliser les outils pour identifier rapidement les erreurs et points de vigilance.

5. Réaliser les tests manuels

Naviguer au clavier, vérifier la structure, les formulaires, les contrastes, les contenus, les composants interactifs et les comportements dynamiques.

6. Tester avec les technologies d’assistance

Vérifier la restitution et l’interaction dans des environnements représentatifs.

7. Observer les usages

Lorsque cela est pertinent, réaliser des tests utilisateurs avec des personnes en situation de handicap.

8. Prioriser les corrections

Toutes les anomalies n’ont pas le même impact. Il est nécessaire de mettre en regard la gravité du problème, le nombre de personnes potentiellement concernées, la fréquence du parcours et l’effort de correction.

9. Refaire les tests

Une correction peut introduire une régression. L’accessibilité doit donc être vérifiée dans la durée, notamment après des évolutions du site.

Tester l’accessibilité dès la conception

L’accessibilité est souvent abordée au moment de la recette finale, lorsque le site est déjà développé. C’est une erreur coûteuse. Plus un problème est identifié tardivement, plus sa correction peut nécessiter de modifier le design, le développement, les contenus ou l’architecture du site.

À l’inverse, intégrer l’accessibilité dès les phases de conception permet de prendre en compte les contraintes liées :

• à la structure de l’information ;
• aux parcours utilisateurs ;
• aux composants d’interface ;
• aux contrastes et à la lisibilité ;
• aux interactions clavier ;
• aux contenus alternatifs ;
• aux formulaires ;
• aux technologies d’assistance.

L’accessibilité devient alors une dimension de la qualité du produit numérique, au même titre que l’utilisabilité, la performance ou la sécurité.

Accessibilité, UX et Facteurs Humains : une même question d’usage

A Ludotic, nous considérons l’accessibilité comme une composante à part entière de l’expérience utilisateur. Notre approche d’Ingénierie Humaine du Numérique permet de croiser plusieurs regards :

• L’accessibilité permet d’identifier les barrières rencontrées par les personnes en situation de handicap.
• L’ergonomie permet d’analyser l’adéquation entre l’interface, les activités et les capacités humaines.
• L’UX permet d’évaluer la qualité de l’expérience et la capacité de l’utilisateur à atteindre ses objectifs, à travers l’intégralité de son parcours (physique et numérique).
• Les Facteurs Humains permettent de prendre en compte les caractéristiques, contraintes et variabilités des personnes et des situations.

Cette complémentarité permet d’aller au-delà de la simple recherche d’erreurs. L’objectif n’est pas uniquement de savoir si une page respecte un critère : il s’agit de comprendre ce que cela change pour la personne qui utilise le service.

Comment savoir si un site est réellement accessible ?

Il n’existe pas de test unique permettant de répondre à cette question.

Une évaluation sérieuse repose sur la combinaison de plusieurs approches :

• un référentiel de référence, comme le RGAA ou les WCAG
• des tests automatisés, pour détecter rapidement certaines erreurs
• des tests manuels, pour vérifier les comportements et la structure
• des tests au clavier et avec des technologies d’assistance
• des tests d’usage, avec de vrais utilisateurs en situation de handicap temporaire ou permanent, lorsque cela est pertinent
• une analyse experte, pour interpréter les résultats et prioriser les actions

Le RGAA lui-même repose sur une méthodologie de test appliquée à un échantillon de pages représentatif. Un critère n’est considéré comme validé pour une page que lorsque les éléments concernés passent les tests prévus.

L’accessibilité ne se résume donc ni à un score, ni à une extension de navigateur, ni à une déclaration. Elle se vérifie dans les usages.

Conclusion

Tester l’accessibilité d’un site web consiste à confronter l’interface à des critères techniques, mais aussi à vérifier sa capacité à être comprise, parcourue et utilisée dans des situations réelles.

Pour une démarche complète, il est recommandé de :

1. définir un périmètre représentatif
2. s’appuyer sur le RGAA ou les WCAG
3. combiner tests automatisés et tests manuels
4. tester la navigation au clavier
5. vérifier les contenus, formulaires, couleurs et composants interactifs
6. utiliser des technologies d’assistance
7. intégrer, lorsque cela est pertinent, des personnes en situation de handicap aux tests
8. prioriser les corrections selon leur impact sur les usages
9. maintenir l’accessibilité dans le temps

L’accessibilité numérique est avant tout une démarche de conception centrée sur les personnes.

Vous souhaitez évaluer l’accessibilité de votre site ?

Ludotic accompagne les organisations dans l’évaluation et l’amélioration de leurs services numériques, en croisant accessibilité, UX, ergonomie et Facteurs Humains.

Nous pouvons intervenir pour réaliser un audit d’accessibilité, identifier les principaux obstacles rencontrés par les utilisateurs et vous aider à transformer les résultats en actions concrètes et prioritaires, ou même organiser un test utilisateur spécial accessibilité.

Contactez-nous pour échanger sur votre projet et découvrir comment nous pouvons vous accompagner !

Vous ne savez pas où vous situez en accessibilité ? Réalisez notre quiz pour découvrir votre niveau dès maintenant !