Lecteur d’écran – screen reader

Un lecteur d’écran (screen reader) est un logiciel d’assistance qui convertit le contenu visuel d’une interface numérique en restitution auditive (synthèse vocale) ou tactile (afficheur braille), permettant aux personnes aveugles, malvoyantes ou en situation de handicap cognitif de naviguer, lire et interagir avec des systèmes informatiques.

Mais au-delà de l’outil, le lecteur d’écran révèle une vérité fondamentale : « Un site n’est pas accessible parce qu’il fonctionne avec un lecteur d’écran. Il fonctionne avec un lecteur d’écran parce qu’il est bien conçu. »

En effet, le lecteur d’écran ne « corrige » pas un mauvais code : il expose la qualité sémantique, structurelle et comportementale de l’interface. Un bouton codé en <div onclick="..."> restera invisible ; un formulaire sans <label> sera incompréhensible.

Outils et technologies de lecture d’écran

1. Lecteurs d’écran libres et open source (recommandés)

OutilPlateformeAvantages DMA
NVDA (NonVisual Desktop Access)WindowsGratuit, open source, mis à jour régulièrement, compatible avec Firefox/Chrome
OrcaLinux (GNOME)Intégré nativement, scriptable, respecte les standards d’accessibilité AT-SPI
EmacspeakLinuxPour développeurs, intégré à l’environnement Emacs

Pour tes tests : NVDA + Firefox est la combinaison la plus proche des usages réels en France (source : enquêtes APF, Agefiph).

2. Lecteurs d’écran propriétaires (intégrés, mais acceptables)

OutilPlateformeRemarque
VoiceOvermacOS, iOS, iPadOSNatif, performant, gratuit, excellent pour tests mobiles
TalkBackAndroidGratuit, intégré, personnalisable
NarrateurWindowsFonctionnel, mais moins complet que NVDA

Ces outils sont acceptables pour le test, car fournis par le système, sans tracking ni abonnement.

3. Affichages braille (complément essentiel)

TechnoRôle
Afficheurs braille USB/Bluetooth (ex. : HumanWare Brailliant, Focus Blue)Restitution tactile en temps réel
Prise en charge via API systèmeWindows (UI Automation), macOS (AX API), Linux (AT-SPI)

Un bon site doit aussi fonctionner avec braille seul (pas de sons). Cela exige des textes alternatifs concis et une structure logique rigoureuse.

4. Outils complémentaires pour les développeurs

OutilUsage
Accessibility Inspector (macOS)Explorer l’arbre d’accessibilité
Windows Accessibility InsightsAudit détaillé, compatible NVDA
axe DevToolsExtension Chrome/Firefox pour repérer erreurs WCAG
WAVEVisualisation des problèmes d’accessibilité directement sur la page

5. Bonnes pratiques pour compatibilité lecteur d’écran

  • HTML sémantique strict : <button>, <nav>, <main>, <h1>
  • Liens significatifs : éviter « cliquez ici », préférer « Lire la définition de »
  • Gestion dynamique des mises à jour : aria-live="polite" pour contenus AJAX
  • Ordre de tabulation logique : cohérent avec la lecture visuelle
  • Pas de contenu caché non pertinent : masquer avec aria-hidden="true" si purement décoratif
  • Tests réels : au moins 10 minutes avec NVDA + clavier, yeux fermés

6. À éviter absolument

  • Les interfaces 100 % JavaScript sans fallback HTML
  • Les carrousels automatiques (désorientent la lecture séquentielle)
  • Les icônes sans texte alternatif (<i class="fa-user"></i> → inaccessible)
  • Les messages d’erreur uniquement visuels (rouge, souligné, etc.)
Les contenus de définition restent publics. Les ressources (outils, grilles, supports) liées à cette fiche sont disponibles dans l’espace membre.