Les lecteurs d'écran ne lisent pas comme toi

Publié le 15 mai 2026Mis à jour le 4 août 2026

13 min de lecture

Lecteur d'écran
HTML
Sémantique
RGAA

Table des matières

Par bonds, pas par lignes

Molly Burke a perdu la vue à quatorze ans. Diagnostiquée à quatre ans avec une rétinite pigmentaire, une maladie génétique rare qui détruit progressivement la rétine, elle a vu les couleurs disparaître à treize ans, puis le monde entier s'éteindre en quelques mois. Aujourd'hui, elle est suivie par plus de 2 millions de personnes sur YouTube, où elle montre entre autres comment elle utilise son iPhone avec VoiceOver.

Regarde l'une de ses vidéos. Ce que tu vas entendre te surprendra probablement : une voix de synthèse qui débite à une vitesse que tu ne comprendras pas. Molly swipe sur son écran, et VoiceOver annonce des fragments. Un nom d'app, un bouton, un message. Pas des phrases continues. Elle ne "lit" pas son téléphone. Elle le navigue, par bonds, à une vitesse que ses yeux ne pourraient pas suivre même s'ils fonctionnaient.

Et c'est exactement ce que font les lecteurs d'écran sur le web. Ils ne lisent pas ta page de haut en bas, mot après mot, comme tu lis cet article. Ils la découpent, la structurent, et offrent à l'utilisateur des raccourcis pour sauter directement à ce qui l'intéresse. Comme toi quand tu scannes visuellement une page pour trouver le bon paragraphe.

Si tu ne comprends pas comment ils fonctionnent, tu risques de construire des pages qui semblent accessibles dans le code mais qui sont inutilisables en pratique.

Le magnétophone qui n'en est pas un

La représentation la plus courante d'un lecteur d'écran, c'est un magnétophone : un outil qui lit tout, du début à la fin, dans l'ordre. C'est faux.

Le sondage WebAIM 2024 a interrogé 1 539 utilisateurs de lecteurs d'écran sur leurs habitudes de navigation. Résultat : 71,6% naviguent par titres quand ils cherchent une information sur une page. Pas en lisant tout. En sautant de <h1> en <h2> en <h3>, comme toi quand tu scannes les sous-titres d'un article pour décider lequel tu vas lire.

Et ce n'est pas la seule stratégie. Les utilisateurs avancés, 76% de ceux qui se déclarent "experts", combinent les titres avec d'autres raccourcis. Chaque lecteur d'écran offre ses propres commandes pour naviguer par type d'élément. Sous NVDA, le plus utilisé en Europe, gratuit et open source, la touche H saute au titre suivant, T au tableau suivant, F au champ de formulaire suivant. Sous VoiceOver sur macOS, le rotor (Ctrl + Option + U) affiche une liste filtrée par type : titres, liens, landmarks, contrôles de formulaire. Les touches diffèrent, le principe est le même : la page est une carte, et l'utilisateur saute de repère en repère.

Mais ces repères n'existent que si ton HTML les déclare. Un titre qui n'est qu'une <div> stylée en gras ? Le lecteur d'écran ne le voit pas. L'utilisateur appuie sur H, ou ouvre le rotor, et rien n'apparaît. La carte est vide. Il ne reste plus qu'à écouter la page entière du début à la fin. Exactement le magnétophone que tu pensais, mais par défaut de structure, pas par choix.

Trois modes, un seul clavier

Quand tu navigues une page web, ton clavier fait une seule chose : envoyer des touches au navigateur. Quand un utilisateur de lecteur d'écran navigue la même page, son clavier fait trois choses différentes selon le contexte, et il bascule entre elles automatiquement.

C'est le mode par défaut. Le lecteur d'écran intercepte les touches avant qu'elles n'atteignent le navigateur et les transforme en commandes de navigation. H ne tape pas la lettre H, il saute au titre suivant. Tab ne passe pas au champ suivant, il avance au prochain élément focusable. L'utilisateur explore une copie linéaire de la page, appelée virtual buffer, que le lecteur d'écran a construite à partir du DOM.

C'est dans ce mode que les raccourcis par type d'élément fonctionnent, et c'est pour ce mode que la structure de ton HTML compte le plus.

Le mode formulaire

Quand l'utilisateur arrive sur un <input>, un <select> ou un <textarea>, le lecteur d'écran bascule automatiquement : il arrête d'intercepter les touches et les laisse passer au navigateur. H tape maintenant la lettre H. Tab passe au champ suivant. L'utilisateur est sorti de la carte pour interagir avec la page.

Ce basculement est transparent quand le HTML est sémantique. Un <input> déclenche le mode formulaire. Une <div contenteditable> pas toujours. Une <div role="textbox">, ça dépend du lecteur d'écran. Encore une fois, le HTML natif est le chemin le plus sûr.

Le mode application

Le troisième mode est le plus dangereux. Quand un élément porte role="application", le lecteur d'écran désactive tous ses raccourcis de navigation et passe le contrôle total du clavier au script de la page. Plus de H pour les titres, plus de raccourcis à une lettre : seul Tab continue de circuler entre les éléments focusables, tout le reste dépend du JavaScript.

Ce mode existe pour les widgets complexes qui gèrent leur propre interaction clavier. Un tableur, un éditeur de code, un jeu. Mais si tu le poses sur un conteneur qui n'implémente pas un comportement clavier complet, l'utilisateur se retrouve enfermé dans une coquille vide. Aucun raccourci du lecteur d'écran, aucun raccourci de ton script. Léonie Watson l'explique en détail : poser role="application" sans implémenter tout le comportement clavier attendu, c'est retirer le volant d'une voiture en marche.

Du HTML à l'oreille

Quand tu écris du HTML, tu penses probablement au rendu visuel. Le navigateur, lui, construit trois choses en parallèle :

Le rendu visuel : ce que tu vois à l'écran
Le DOM : l'arbre des éléments HTML que JavaScript peut manipuler
L'arbre d'accessibilité : une version simplifiée du DOM, débarrassée du décor, qui ne garde que ce qui a du sens pour les technologies d'assistance

L'arbre d'accessibilité est ce que le lecteur d'écran lit. Pas le DOM. Pas le CSS. Pas le rendu visuel. Une <div> avec un font-weight: bold et un font-size: 24px ? Dans l'arbre d'accessibilité, c'est un élément générique sans rôle ni sémantique. Il n'existe pas comme titre. Un <h2> sans aucun style ? C'est un titre de niveau 2, le lecteur d'écran l'annonce, et l'utilisateur peut sauter dessus avec le raccourci de navigation.

Tu peux inspecter l'arbre d'accessibilité de n'importe quelle page dans les outils de développement de ton navigateur, onglet Accessibility. C'est la vue la plus révélatrice de ce que ton HTML communique réellement et de ce qu'il oublie de dire.

L'AOM : manipuler l'arbre depuis JavaScript

Le DOM a son API JavaScript — document.querySelector, element.setAttribute. L'arbre d'accessibilité n'en avait pas. La seule façon de modifier ce qu'un lecteur d'écran voyait d'un élément, c'était de poser des attributs ARIA dans le HTML. aria-label, role, aria-expanded. Ça marche, mais ça pollue le DOM avec des attributs qui n'ont rien à voir avec la structure du document.

L'Accessibility Object Model (AOM) est une API en cours de développement, portée par Apple, Google et Mozilla, qui vise à donner un accès JavaScript direct à l'arbre d'accessibilité. Sa première phase, la réflexion des propriétés ARIA en propriétés JavaScript sur les éléments DOM, est déjà supportée dans Chromium, Firefox et Safari, avec des niveaux de couverture variables.

aom-reflection.js

// Avant l'AOM : attribut HTML
button.setAttribute("aria-expanded", "true");
 
// Avec l'AOM : propriété réfléchie (écrit le même attribut)
button.ariaExpanded = "true";

La différence est plus mince qu'il n'y paraît : la propriété est une réflexion de l'attribut. button.ariaExpanded = "true" écrit aria-expanded="true" dans le DOM, exactement comme setAttribute. Le gain est ergonomique (une propriété typée, découvrable, sans chaîne de caractères à orthographier), pas structurel. Pour définir la sémantique d'un composant sans toucher au HTML généré, c'est ElementInternals, la deuxième brique de l'AOM, qui fait le travail.

L'AOM va plus loin avec ElementInternals, qui permet aux custom elements de déclarer leur sémantique par défaut. Un <my-button> peut se comporter comme un <button> pour le lecteur d'écran sans aucun attribut ARIA visible. Les phases suivantes, requêtes sur l'arbre d'accessibilité calculé, nœuds virtuels, sont encore en développement, mais la direction est claire. L'arbre d'accessibilité devient un citoyen de première classe de la plateforme web, au même titre que le DOM et le rendu visuel.

Un paysage, pas un outil

Il n'y a pas "le" lecteur d'écran. Il y a un écosystème, avec des parts de marché, des comportements différents, et des utilisateurs qui en combinent souvent plusieurs.

Le sondage WebAIM 2024 donne une photo claire :

Sur ordinateur :

JAWS : 40,5% (leader en Amérique du Nord, payant : licence perpétuelle autour de 1 000 $, ou abonnement annuel à moins de 100 $)
NVDA : 37,7% (leader en Europe et en Asie, gratuit et open source)
VoiceOver : 9,7% (intégré à macOS, gratuit)
Narrator : 0,7% en usage principal (intégré à Windows, 37,3% des répondants l'utilisent occasionnellement)

Sur mobile :

VoiceOver (iOS) : 70,6%
TalkBack (Android) : 34,7%

Deux chiffres à retenir : 91,3% des répondants utilisent un lecteur d'écran sur mobile. Le web mobile n'est pas secondaire, il est primaire. Et 65,6% utilisent NVDA au total (pas seulement en usage principal). C'est le lecteur le plus répandu si on compte tous les usages.

Ce qui compte pour toi : JAWS et NVDA partagent le même concept de virtual buffer et plusieurs raccourcis de navigation. H pour les titres, T pour les tableaux, F pour les champs de formulaire, mais pas tous. NVDA utilise D pour les landmarks là où JAWS utilise R. NVDA a une touche K pour sauter au lien suivant, et les deux distinguent les liens non visités (U) des liens visités (V). VoiceOver fonctionne encore différemment, un rotor au lieu de raccourcis à une lettre, navigation par gestes sur iOS. Les raccourcis exacts changent, le principe reste le même. La page est une carte, et chaque lecteur d'écran offre ses propres commandes pour la parcourir.

C'est pour ça que tester sur un seul lecteur d'écran ne suffit pas, et c'est aussi pour ça que le HTML natif est le chemin le plus sûr. Un <button> fonctionne correctement sur tous les lecteurs d'écran. Une <div role="button"> fonctionne différemment sur chacun.

Le test en 5 minutes

Tu n'as pas besoin de maîtriser un lecteur d'écran pour vérifier que ta page est navigable. Mais tu dois en utiliser un. L'arbre d'accessibilité dans les outils de développement montre la structure, pas l'expérience. Il ne te dit pas si le focus se déplace correctement, si le basculement entre mode navigation et mode formulaire fonctionne, ni si l'annonce vocale a du sens dans le flux de lecture. C'est un outil de diagnostic, pas un substitut au test réel.

VoiceOver sur macOS

Cmd + F5 : active VoiceOver
Ctrl + Option + U : ouvre le rotor
Flèches gauche/droite : bascule entre les listes de titres, liens, landmarks, contrôles de formulaire
Flèches haut/bas : navigue dans la liste sélectionnée
Entrée : saute à l'élément choisi
Cmd + F5 : désactive VoiceOver

Ce que tu vérifies : est-ce que la liste des titres reflète la structure de ta page ? Est-ce que tous tes liens ont un intitulé compréhensible hors contexte ? Est-ce que tes landmarks (<nav>, <main>, <aside>) apparaissent ?

NVDA sur Windows

NVDA est gratuit. Installe-le, ouvre ta page, et :

Insert + F7 : ouvre la liste des éléments (titres, liens, landmarks)
H : titre suivant
D : landmark suivant
Tab : élément focusable suivant
Insert + Espace : bascule entre mode navigation et mode formulaire

L'arbre d'accessibilité dans le navigateur

Si tu ne peux pas installer de lecteur d'écran, l'arbre d'accessibilité dans les outils de développement (F12, onglet Accessibility) reste utile pour un premier diagnostic. Tu y vois le rôle, le nom accessible et les états de chaque élément. Mais garde en tête que c'est une radiographie, pas un examen clinique. Ça montre l'anatomie, pas le fonctionnement. Un élément peut avoir le bon rôle dans l'arbre et rester inutilisable au clavier, ou être annoncé de manière incompréhensible dans le flux de lecture.

Les critères d'ensemble

Le RGAA encadre la structure et la navigation qui permettent aux lecteurs d'écran de fonctionner :

RGAA 9.1 — l'information est structurée par l'utilisation appropriée de titres
RGAA 9.2 — la structure du document est cohérente (les zones d'en-tête, de navigation, de contenu principal et de pied de page sont correctement déclarées)
RGAA 12.6 — les zones de regroupement de contenu sont atteignables ou évitables

Ces critères garantissent que la "carte" de la page existe, que les titres sont hiérarchisés, que les régions sont identifiées, et que l'utilisateur peut naviguer efficacement au lieu de subir un flux linéaire.