Comment fonctionne un lecteur d'écran ?

Il parcourt l'arbre d'accessibilité construit par le navigateur et restitue chaque élément en synthèse vocale ou sur un afficheur braille, avec son nom, son rôle et son état. La lecture est séquentielle, ce qui rend l'ordre du code déterminant : ce qui vient avant dans le document est annoncé avant.

Quels raccourcis permettent de parcourir une page rapidement ?

Les commandes de saut par type d'élément : une touche pour aller de titre en titre, une autre pour les liens, une autre pour les champs de formulaire, une autre pour les régions. L'utilisateur ne lit presque jamais une page en entier, il la balaie par sauts successifs.

Pourquoi les points de repère sont-ils importants ?

Parce qu'ils fonctionnent comme la carte de la page : ils permettent d'atteindre directement le contenu principal, la navigation ou la recherche. Sans eux, l'utilisateur retraverse l'en-tête et le menu à chaque nouvelle page du même site.

Comment les lecteurs d'écran restituent réellement une page web

Pour 21 millions de personnes dans le monde, le web n'est pas une expérience visuelle. C'est un flux sonore ou tactile (braille) qui transforme chaque page en narration séquentielle.

Comprendre comment fonctionnent les lecteurs d'écran change radicalement votre approche du développement web.

Qu'est-ce qu'un lecteur d'écran ?

Un lecteur d'écran est un logiciel qui interprète le contenu affiché à l'écran et le restitue de manière non visuelle :

Synthèse vocale : Le texte est lu à haute voix par une voix synthétique. L'utilisateur peut ajuster la vitesse (souvent très rapide pour les utilisateurs expérimentés).

Afficheur braille : Le texte apparaît sur une barrette de cellules braille rafraîchissables. Option privilégiée par les utilisateurs sourds-aveugles.

Le lecteur d'écran ne "voit" pas la page comme vous. Il parcourt l'arbre d'accessibilité (accessibility tree) construit par le navigateur à partir de votre HTML.

Les lecteurs d'écran les plus utilisés

JAWS (Windows) - 41% de part de marché

Développé par Freedom Scientific, JAWS (Job Access With Speech) est le leader historique. Logiciel commercial (environ 1 000 euros), il offre la meilleure compatibilité avec les applications Windows professionnelles.

NVDA (Windows) - 38% de part de marché

NonVisual Desktop Access est gratuit et open source. Son adoption a fortement progressé, rivalisant désormais avec JAWS. C'est l'outil recommandé pour tester l'accessibilité de vos sites.

VoiceOver (macOS/iOS) - 72% sur mobile

Intégré gratuitement aux appareils Apple, VoiceOver domine le marché mobile. Son intégration native garantit une expérience fluide sur iPhone, iPad et Mac.

TalkBack (Android) - 29% sur mobile

L'équivalent Google pour Android. Moins utilisé que VoiceOver car l'écosystème Android est plus fragmenté.

Note

Les utilisateurs expérimentés utilisent souvent plusieurs lecteurs d'écran selon le contexte. Tester avec un seul outil ne suffit pas pour garantir une compatibilité universelle.

Comment un utilisateur navigue-t-il sur une page ?

Navigation lineaire : L'utilisateur parcourt la page élément par élément avec les flèches. C'est lent mais exhaustif.

Navigation par type d'élément : Des raccourcis clavier permettent de sauter directement aux éléments souhaités :

Raccourci	Action
H	Titre suivant
1-6	Titre de niveau spécifique
F	Champ de formulaire suivant
B	Bouton suivant
L	Liste suivante
T	Tableau suivant
K	Lien suivant

Cette navigation par raccourcis permet de scanner une page rapidement, comme un utilisateur voyant balaierait visuellement les titres.

L'importance de la structure sémantique

Si votre page n'utilise pas de vrais titres (<h1> à <h6>), la touche H ne fonctionne pas. L'utilisateur est forcé de parcourir linéairement des centaines d'éléments.

C'est pourquoi la structure sémantique n'est pas un luxe technique : c'est le système de navigation principal des utilisateurs de lecteurs d'écran.

Astuce

Testez votre site avec notre outil d'audit qui détecte les problèmes de structure de titres et de navigation.

Ce que le lecteur d'écran annonce

Pour chaque élément rencontré, le lecteur annonce :

Le rôle : "Titre de niveau 2", "Lien", "Bouton", "Image"
Le nom/contenu : Le texte visible ou l'attribut accessible
L'état (si applicable) : "Coché", "Non coché", "Développé", "Réduit"

Exemple d'annonce pour un lien image :

CODE

<a href="/contact">
  <img src="email.png" alt="Nous contacter">
</a>

Annonce : "Lien, Nous contacter"

Si l'alt est manquant : Annonce : "Lien, email.png" (le nom du fichier, inutile)

Les landmarks : la carte de votre page

Les landmarks (régions) permettent aux utilisateurs de sauter directement aux grandes sections :

CODE

<header>...</header>      <!-- "Banniere" -->
<nav>...</nav>            <!-- "Navigation" -->
<main>...</main>          <!-- "Contenu principal" -->
<aside>...</aside>        <!-- "Information complémentaire" -->
<footer>...</footer>      <!-- "Informations de pied de page" -->

L'utilisateur peut lister toutes les régions et naviguer directement vers celle qui l'intéresse. Sans landmarks, il doit parcourir tout le contenu séquentiellement.

Mode formulaire / mode saisie

Quand l'utilisateur entre dans un champ de formulaire, le lecteur passe en "mode saisie". Les raccourcis de navigation sont désactivés pour permettre la frappe.

C'est pourquoi les labels sont critiques : en mode saisie, l'utilisateur ne peut pas explorer autour du champ pour comprendre son contexte.

Mode tableau

Dans un tableau, la navigation se fait par cellules (flèches directionnelles). Le lecteur annonce les en-têtes de ligne et colonne pour chaque cellule.

Un tableau sans en-têtes (<th>) devient une grille de données incompréhensible : "Cellule, 42" sans savoir si c'est un prix, une quantité ou une date.

Les erreurs les plus frustrantes pour les utilisateurs

Une étude auprès de 100 utilisateurs aveugles a identifié les principales sources de frustration :

1. Mise en page confuse

Le lecteur d'écran suit l'ordre du DOM, pas l'ordre visuel. Si votre CSS réorganise visuellement les éléments, l'ordre de lecture peut devenir incohérent.

2. Formulaires sans labels

"Champ de saisie, vide" - L'utilisateur ne sait pas ce qu'il doit entrer.

3. Absence de texte alternatif

"Image" ou "photo1234.jpg" n'apportent aucune information.

4. Liens non explicites

"Cliquez ici" - Où ça ? Pour quoi faire ? Hors contexte, le lien est incompréhensible.

5. Popups et contenus dynamiques non annoncés

Une modale qui s'ouvre sans que le focus se déplace laisse l'utilisateur perdu dans la page précédente.

Note

Les utilisateurs perdent en moyenne 30% de leur temps à cause de ces problèmes de conception. Un site accessible est aussi un site plus rapide pour eux.

Tester avec un lecteur d'écran

Installation de NVDA (gratuit)

Téléchargez NVDA sur nvaccess.org
Lancez-le (Insert + Q pour quitter)
Naviguez sur votre site uniquement au clavier
Écoutez les annonces

Premiers tests à réaliser

Navigation par titres (H) : Pouvez-vous comprendre la structure de la page ?
Liste des liens (Insert + F7) : Les intitulés sont-ils explicites hors contexte ?
Formulaires (F) : Chaque champ a-t-il un label annoncé ?
Images : Les informations importantes sont-elles décrites ?

Conseil pratique

Au début, vous trouverez la synthèse vocale difficile à suivre. Les utilisateurs expérimentés l'écoutent à 3x ou 4x la vitesse normale. C'est une compétence qui s'acquiert.

Impact sur vos développements

Comprendre les lecteurs d'écran transforme votre code :

HTML sémantique : Utilisez les balises appropriées (<button>, <nav>, <article>) plutôt que des <div> stylées.

Ordre logique du DOM : Assurez-vous que l'ordre du code correspond à l'ordre de lecture souhaité.

ARIA avec parcimonie : N'utilisez ARIA que quand HTML natif ne suffit pas. Un mauvais ARIA est pire que pas d'ARIA.

Focus visible et logique : Le parcours au clavier doit suivre un ordre prévisible.

Consultez notre guide ARIA et notre comparatif des lecteurs d'écran pour approfondir.

Le web comme expérience auditive

Pour les utilisateurs de lecteurs d'écran, votre site est une narration audio. Chaque élément mal structuré, chaque image non décrite, chaque lien vague brise cette narration.

Concevoir pour les lecteurs d'écran, c'est concevoir pour la clarté. Et un site clair pour un lecteur d'écran est un site clair pour tous.