Tester son site au lecteur d'écran : NVDA, VoiceOver, TalkBack — le guide pas à pas
En bref — le test que les scanners ne remplacent pas
Le lecteur d'écran lit la page à voix haute pour les personnes aveugles ou malvoyantes. Tester votre site avec l'un d'eux révèle ce qu'aucun outil automatique ne voit : un texte alternatif vide de sens, un bouton sans nom, un message d'erreur jamais annoncé. Vous pouvez le faire vous-même, gratuitement :
- NVDA (Windows) — gratuit et open source, le plus simple pour commencer ;
- VoiceOver (Mac, iPhone, iPad) — déjà intégré, rien à installer ;
- TalkBack (Android) — intégré au téléphone, pour tester la version mobile.
La règle d'or : ne testez pas « la page », testez un vrai parcours (trouver un produit → l'ajouter au panier → payer), les yeux fermés ou l'écran éteint. La compatibilité avec les technologies d'assistance est exigée par l'EAA (norme EN 301 549 / WCAG 2.1 AA) ; le test au lecteur d'écran est la façon concrète de la vérifier.
Un outil d'audit automatique repère vite les manquements mécaniques, mais il ne sait pas écouter votre site. Or c'est exactement ainsi que des millions de personnes l'utilisent. Bonne nouvelle : vous n'avez besoin d'aucun logiciel payant ni d'aucune compétence rare pour faire un premier test sérieux. Voici comment choisir un lecteur d'écran, les quelques commandes qui suffisent, et surtout quoi tester — avec les limites à garder honnêtement en tête.
Pourquoi tester à l'oreille, pas seulement à l'œil
Les outils automatiques ne couvrent qu'une partie des critères WCAG (souvent estimée autour de 30 % des problèmes, jusqu'à ~57 % selon l'éditeur d'axe-core — toujours une minorité ou la moitié au mieux). Le reste demande un jugement humain, et le lecteur d'écran est l'outil qui le rend audible : il vous fait entendre ce qu'une personne aveugle perçoit. Un bouton « panier » qui s'annonce « bouton » tout court, une image de produit lue « image IMG_4821.jpg », un « ajouté au panier » qui n'est jamais prononcé : ces barrières passent inaperçues à l'œil et au scanner, mais sautent à l'oreille en dix secondes.
Côté norme, le principe WCAG n°4 (« Robuste ») exige un code compatible avec les technologies d'assistance, et l'EN 301 549 réclame cette interopérabilité. Aucune loi n'impose un lecteur d'écran précis : l'exigence est neutre. Mais tester avec un lecteur réel reste le moyen le plus direct de vérifier que votre code tient cette promesse.
Choisir et lancer un lecteur d'écran
Commencez par le gratuit, sur la plateforme que vous avez
Pas besoin de tout installer : prenez celui qui correspond à votre matériel. Sur Windows, NVDA (NV Access) est gratuit, open source et téléchargeable en deux minutes — c'est le point de départ idéal. Sur Mac, iPhone ou iPad, VoiceOver est déjà là. Sur Android, TalkBack aussi. Le lecteur dominant en entreprise, JAWS (Freedom Scientific), est payant ; inutile pour un premier test, NVDA suffit.
Chaque lecteur s'apprécie avec un navigateur précis (ils dialoguent via les API d'accessibilité) : NVDA avec Firefox ou Chrome, VoiceOver avec Safari, JAWS avec Chrome, TalkBack avec Chrome. D'après l'enquête utilisateurs de WebAIM (2024), JAWS, NVDA et VoiceOver se partagent l'essentiel des usages — tester avec NVDA et VoiceOver couvre déjà une large part de vos visiteurs réels.
→ Voir aussi les outils d'audit automatiques (complémentaires).
Tout un test avec une poignée de touches
Téléchargez NVDA sur le site de NV Access, installez-le, puis lancez-le avec Ctrl+Alt+N. La « touche NVDA » (le modificateur) est par défaut Inser (ou le 0 du pavé numérique). Vous n'avez besoin que de quelques raccourcis :
- Lire en continu (à partir du curseur) :
NVDA + Flèche bas; - Naviguer par titre :
H(et1…6par niveau) ; - Par région (en-tête, navigation, contenu) :
D; par champ de formulaire :F; par lien :K; par bouton :B; - Liste de tous les éléments (titres, liens, repères) :
NVDA + F7— la meilleure vue d'ensemble de votre page ; - Basculer mode navigation / mode formulaire :
NVDA + Espace(en mode formulaire, vos frappes vont dans le champ) ; - Quitter :
NVDA + Q.
NVDA+F7 pour voir si les titres dessinent un plan logique, puis Tab jusqu'au bouton d'ajout au panier pour entendre comment il s'annonce.→ Voir aussi la structure des titres.
Rien à télécharger, sur Safari de préférence
Sur Mac, activez/coupez VoiceOver avec Cmd + F5. Le modificateur VoiceOver est Contrôle + Option (noté « VO »). Déplacez-vous élément par élément avec VO + Flèche droite / Flèche gauche ; ouvrez le rotor (VO + U) pour sauter directement aux titres, aux liens ou aux champs de formulaire. Testez de préférence dans Safari, qui expose pleinement les informations d'accessibilité.
Sur iPhone / iPad, activez VoiceOver depuis Réglages → Accessibilité (ou par un triple-clic du bouton latéral si vous l'avez configuré). Balayez vers la droite pour passer à l'élément suivant, touchez l'écran pour explorer, et faites un double-tap pour activer l'élément sélectionné. Le rotor s'ouvre en tournant deux doigts sur l'écran. C'est le moyen le plus fidèle de tester votre site tel qu'un utilisateur mobile aveugle le vit.
→ Voir aussi l'accessibilité mobile.
Le lecteur d'écran intégré à Android
TalkBack (Google) est gratuit et intégré : activez-le dans Réglages → Accessibilité → TalkBack, ou par le raccourci des deux touches de volume maintenues. La navigation se fait au doigt : faites glisser lentement pour explorer ce qui est sous votre doigt, balayez pour passer d'un élément au suivant, et double-tap pour activer (bouton, lien, champ). Testez sur Chrome, le couple le mieux pris en charge sous Android.
→ Voir aussi le tunnel de commande.
Un vrai parcours d'achat, pas une simple lecture
Ne vous contentez pas d'écouter la page d'accueil. Refaites un parcours complet — trouver un produit, le configurer, l'ajouter au panier, aller jusqu'au paiement — et vérifiez à l'oreille :
- les images produit sont-elles décrites utilement, ou lues « image » / nom de fichier ? (1.1.1) ;
- les titres et listes s'annoncent-ils correctement et dans un ordre logique ? (1.3.1, 1.3.2) ;
- l'ordre de lecture et de focus suit-il la logique visuelle ? (2.4.3) ;
- chaque lien est-il compréhensible hors contexte (pas « cliquez ici » en boucle) ? (2.4.4) ;
- les champs ont-ils une étiquette annoncée, et les erreurs sont-elles lues et reliées au bon champ ? (3.3.1, 3.3.2) ;
- les composants (onglets, menu, sélecteur de quantité) annoncent-ils leur nom, leur rôle et leur état ? (4.1.2) ;
- les messages dynamiques (« ajouté au panier », « 3 résultats ») sont-ils annoncés sans déplacer le focus ? (4.1.3).
→ Voir aussi les messages d'erreur accessibles.
Un test utile, mais pas un substitut
Tester soi-même au lecteur d'écran fait progresser énormément, mais deux pièges : d'abord, un développeur voyant qui apprend le lecteur d'écran ne vit pas l'expérience comme une personne qui l'utilise tous les jours — on peut manquer des barrières ou, à l'inverse, s'alarmer d'un comportement normal mal compris. Ensuite, il faut un minimum de pratique pour ne pas confondre « je ne sais pas m'en servir » et « le site est cassé ». Le test maison est un excellent filet de sécurité ; pour une validation forte, rien ne remplace un test avec de vraies personnes en situation de handicap et, si l'enjeu est élevé, un audit professionnel.
→ Voir aussi le coût d'une mise en conformité.
Récapitulatif : quel lecteur d'écran pour quoi
| Lecteur | Plateforme | Coût | Navigateur conseillé |
|---|---|---|---|
| NVDA | Windows | Gratuit, open source | Firefox ou Chrome |
| VoiceOver | Mac, iPhone, iPad | Gratuit, intégré | Safari |
| TalkBack | Android | Gratuit, intégré | Chrome |
| JAWS | Windows | Payant (licence) | Chrome |
Et après le test ? (ce que DeclareAccess ajoute)
Le test au lecteur d'écran vous dit ce qui coince à l'oreille. Pour le reste — les manquements mécaniques (contraste, alternatives manquantes, noms de boutons) — un scanner automatique va plus vite. Les deux sont complémentaires : lancez un audit auto pour la partie mesurable, puis votre test lecteur d'écran pour la partie humaine.
Là où DeclareAccess intervient : notre audit automatisé (moteur axe-core, WCAG 2.1 AA) vous envoie le rapport des manquements détectables sans rien installer, liste les vérifications manuelles à mener vous-même (dont ce test lecteur d'écran), et surtout génère la déclaration d'accessibilité légale que l'EAA impose de publier — modèle français (RGAA), allemand (BFSG), italien ou espagnol. Nous restons honnêtes sur la frontière : l'outil trouve le mesurable, vous validez l'humain.
Auditez votre boutique sans rien installer
DeclareAccess analyse une page de votre site avec le moteur axe-core selon les WCAG 2.1 AA, vous envoie le rapport des manquements détectables et la liste des vérifications manuelles à mener, puis génère la déclaration d'accessibilité prête à publier — modèle français (RGAA), allemand (BFSG), italien ou espagnol. Gratuit, sans carte bancaire.
Rapport WCAG par e-mail sous 24 h ouvrées.
C'est noté. Votre client e-mail va s'ouvrir avec la demande pré-remplie — il vous suffit de l'envoyer.
Questions fréquentes
Quel lecteur d'écran utiliser pour tester gratuitement ?
NVDA sur Windows (gratuit et open source, à télécharger chez NV Access) ou VoiceOver sur Mac/iPhone (déjà intégré, rien à installer). Pour la version mobile Android, TalkBack est intégré au téléphone. NVDA + Firefox et VoiceOver + Safari sont les couples recommandés pour des résultats fiables. JAWS est très répandu mais payant : inutile pour un premier test.
Faut-il être aveugle ou expert pour faire ce test ?
Non. Quelques commandes suffisent pour un premier test utile, et l'essentiel est de refaire un vrai parcours d'achat les yeux fermés ou l'écran éteint. Gardez toutefois en tête qu'un test par une personne voyante ne reproduit pas exactement l'expérience d'un utilisateur aveugle quotidien : c'est un excellent filet de sécurité, pas un substitut à un test avec de vraies personnes en situation de handicap.
Que révèle le lecteur d'écran qu'un outil automatique ne voit pas ?
La qualité réelle des textes alternatifs (1.1.1), l'ordre de lecture et de focus (1.3.2, 2.4.3), la clarté des liens hors contexte (2.4.4), l'annonce des étiquettes et des erreurs de formulaire (3.3.1, 3.3.2), le nom/rôle/état des composants personnalisés (4.1.2) et l'annonce des messages dynamiques comme « ajouté au panier » (4.1.3). Un scanner ne couvre qu'environ 30 à 50 % des critères WCAG ; le reste se vérifie ainsi.
La loi impose-t-elle de tester avec un lecteur d'écran précis ?
Non. L'EAA et la norme EN 301 549 (alignée sur WCAG 2.1 AA) exigent un code compatible avec les technologies d'assistance, mais l'exigence est neutre : aucun lecteur d'écran nommé n'est imposé. Tester avec un lecteur réel (NVDA, VoiceOver…) reste simplement le moyen le plus direct de vérifier que votre site tient cette obligation de compatibilité.
Quel navigateur associer à chaque lecteur d'écran ?
NVDA avec Firefox ou Chrome, VoiceOver avec Safari, JAWS avec Chrome, TalkBack avec Chrome. Le lecteur et le navigateur dialoguent via les API d'accessibilité du système : un couple mal assorti (par exemple VoiceOver hors Safari) peut produire des bugs qui ne viennent pas de votre site. Pour comparer, gardez toujours le même couple d'un test à l'autre.