Tester avec un lecteur d’écran : NVDA, VoiceOver, TalkBack
Les outils automatiques de test d'accessibilité détectent environ 30 % des problèmes. Le reste ne se révèle qu'avec un vrai lecteur d'écran. Ce guide vous donne les bases pour tester vous-même.
Les outils automatiques de test d’accessibilité — axe, Lighthouse, WAVE — sont rapides et faciles à utiliser. Ils détectent les problèmes structurels évidents : images sans alternative, champs de formulaire sans étiquette, contrastes insuffisants. Mais ils passent à côté de l’essentiel : est-ce que la page est compréhensible et navigable avec un lecteur d’écran ? Ce guide vous donne les bases pour le tester vous-même, sans être expert en accessibilité.
Quel lecteur d’écran choisir ?
| Lecteur d’écran | Environnement | Coût | Pour commencer |
|---|---|---|---|
| NVDA | Windows (avec Chrome ou Firefox) | Gratuit (open source) | Télécharger sur nvaccess.org ; raccourcis listés dans le guide de démarrage rapide |
| VoiceOver | macOS, iOS, iPadOS | Intégré au système | Activer : cmd+F5 sur Mac, paramètres → Accessibilité → VoiceOver sur iOS |
| TalkBack | Android | Intégré au système | Activer : paramètres → Accessibilité → TalkBack (variantes selon constructeur) |
| JAWS | Windows (professionnel) | Payant | Standard de référence en entreprise ; accès en mode essai disponible |
Pour débuter, NVDA + Chrome sur Windows est le point de départ le plus courant : gratuit, largement utilisé, raccourcis documentés. Tester ensuite sur VoiceOver + Safari sur iOS si l’audience mobile est importante.
Installation et configuration minimale
- NVDA Télécharger sur nvaccess.org. Au premier lancement, choisir le niveau de verbosité (démarrer avec « Moyen »). Activer le mode navigation (F7 pour la liste des éléments). Utiliser avec Chrome ou Firefox, pas avec Edge au démarrage — le comportement est différent.
- VoiceOver macOS Activer avec cmd+F5. La combinaison de base est VO (caps lock ou ctrl+alt). Lire la page : VO+A. Passer à l’élément suivant : tab (éléments interactifs) ou VO+flèche (tous les éléments). Le rotor (VO+U) donne accès aux listes de liens, titres, formulaires.
- VoiceOver iOS Activer dans Paramètres → Accessibilité → VoiceOver. Glisser un doigt pour explorer, double-taper pour activer, glisser 3 doigts pour défiler. Prévoir 15 minutes de prise en main avant le premier test.
- TalkBack Android Activer dans Paramètres → Accessibilité → TalkBack. Explorer en glissant un doigt ; activer en double-tapant. Le menu contextuel TalkBack (glisser haut puis droite) donne accès aux modes de navigation.
Les 5 parcours à tester en priorité
- Navigation clavier pure — désactiver la souris, naviguer avec tab, shift+tab, entrée, espace et flèches. Toutes les fonctionnalités doivent être accessibles. L’indicateur de focus doit être visible à chaque étape.
- Formulaires — chaque champ doit avoir une étiquette annoncée par le lecteur d’écran. Les messages d’erreur doivent être lus automatiquement (rôle alert ou focus envoyé sur le message). Les champs obligatoires doivent être annoncés.
- Images — les images porteuses d’information doivent avoir une alternative textuelle pertinente (pas « image1.jpg » ni une répétition du texte adjacent). Les images décoratives doivent être ignorées (alt= » » ou rôle=none).
- Titres et structure — naviguer de titre en titre (H dans NVDA). La hiérarchie doit refléter la structure logique de la page. Un titre h2 après un h3 est un problème.
- Composants dynamiques — modales, accordéons, onglets, menus déroulants. Le focus doit entrer dans la modale à l’ouverture, rester piégé à l’intérieur pendant qu’elle est ouverte, et revenir à l’élément déclencheur à la fermeture. Les changements d’état (accordéon ouvert/fermé) doivent être annoncés.
Un élément peut avoir l’air correct visuellement et être totalement inaccessible au lecteur d’écran. Exemple classique : un bouton implémenté comme <div onclick> sans rôle, ni tabindex, ni annonce — il est invisible pour le lecteur d’écran. Les tests visuels ne détectent jamais ces problèmes.
Grille de vérification rapide
| Point de vérification | Comment le tester |
|---|---|
| Alternative aux images | Naviguer sur les images avec NVDA (I) ; vérifier ce qui est lu |
| Étiquettes de formulaire | Cliquer dans un champ ; vérifier que le lecteur d’écran annonce le libellé |
| Ordre de lecture logique | VO+A (VoiceOver) ou NVDA+flèche bas : le texte doit s’enchaîner de façon cohérente |
| Focus visible | Naviguer au clavier yeux ouverts ; l’indicateur de focus doit être toujours visible |
| Liens descriptifs | Naviguer sur les liens (K dans NVDA) ; « Cliquez ici » n’est pas descriptif hors contexte |
Notre expertise en accessibilité web accompagne les équipes de développement dans la mise en conformité RGAA et WCAG. Notre offre Accessibilité et inclusion couvre l’audit, la formation et le suivi de la conformité.
Questions fréquentes
Combien de temps faut-il pour tester une page avec un lecteur d'écran ?
Une page d'accueil ou un formulaire de contact : 20 à 45 minutes pour un testeur non expert. Un parcours complet d'achat ou d'inscription : 1 à 2 heures. Le premier test est plus long car il faut apprendre les raccourcis ; les suivants sont nettement plus rapides.
Faut-il être non-voyant pour tester avec un lecteur d'écran ?
Non. Les tests par des voyants avec les yeux ouverts sont utiles pour identifier les problèmes techniques. Les tests avec les yeux fermés ou bandés révèlent l'expérience réelle des utilisateurs non-voyants. Les deux sont utiles ; commencer par les tests yeux ouverts est plus facile.
Les tests avec un lecteur d'écran remplacent-ils les tests avec des utilisateurs en situation de handicap ?
Non. Les tests techniques révèlent les problèmes de code. Les tests avec des utilisateurs réels révèlent les problèmes d'expérience, de formulation et de flux qui ne sont pas visibles dans le code. Les deux sont complémentaires.