Lecteurs d’écran expliqués : comment les personnes aveugles naviguent sur le Web

On estime qu’il y a 36 millions de personnes aveugles dans le monde, et environ 217 millions d’autres vivent avec une déficience visuelle modérée à sévère. Pourtant, en 2025, plus de 96 % des sites web présentent encore au moins une défaillance d’accessibilité détectable. Pour une personne aveugle qui s’appuie sur un lecteur d’écran, une seule étiquette manquante, une hiérarchie de titres cassée ou un CAPTCHA inaccessible peut faire la différence entre accomplir une tâche de manière autonome et abandonner complètement votre site. Comprendre comment les lecteurs d’écran fonctionnent réellement — non seulement en théorie, mais en pratique — est la base de la création d’un web accessible.

Qu’est-ce qu’un lecteur d’écran et qui en utilise un ?

Un lecteur d’écran est un logiciel d’assistance qui convertit le contenu à l’écran en synthèse vocale ou en sortie braille rafraîchissable. Plutôt que de simplement lire le texte à voix haute, les lecteurs d’écran interprètent la structure, les rôles, les états et les relations des éléments d’interface, donnant aux utilisateurs une compréhension complète d’une page web sans dépendre de la présentation visuelle. Pensez-y moins comme un narrateur et davantage comme un interprète intelligent qui traduit toute votre interface visuelle en un flux d’informations audio ou tactile.

Les lecteurs d’écran sont principalement utilisés par des personnes aveugles ou malvoyantes, mais ils soutiennent aussi des utilisateurs ayant certains handicaps cognitifs ou de lecture. Selon la 10e enquête sur les utilisateurs de lecteurs d’écran de WebAIM — menée fin 2023 et publiée en février 2024 — près de 77 % des utilisateurs de lecteurs d’écran sont des personnes aveugles, suivies par des personnes malvoyantes ou ayant d’autres déficiences visuelles à près de 20 %. La perte auditive, les handicaps cognitifs et les handicaps moteurs représentent le reste. Il ne s’agit pas d’un public de niche : 4,9 % des adultes aux États-Unis ont une déficience visuelle avec cécité ou difficulté sérieuse à voir, et le nombre d’utilisateurs ayant une déficience visuelle dans le monde se compte en centaines de millions.

Il est également important de noter que les utilisateurs de lecteurs d’écran ne forment pas un groupe homogène. La recherche montre de manière constante une grande diversité de compétences, de préférences, de stratégies de navigation et d’approches de dépannage. Une personne aveugle de naissance qui utilise JAWS depuis vingt ans navigue de manière très différente de quelqu’un qui a récemment perdu la vue et est encore en train d’apprendre la technologie d’assistance. Même des sites techniquement accessibles peuvent présenter des difficultés importantes lorsque les modèles mentaux qu’ils exigent ne correspondent pas aux attentes d’un utilisateur. Les designers et développeurs doivent résister à la tentation d’imaginer un seul utilisateur archétypal de lecteur d’écran.

Comment les lecteurs d’écran fonctionnent réellement : l’arbre d’accessibilité

Pour vraiment comprendre les lecteurs d’écran, vous devez comprendre ce qu’ils lisent — et ce n’est pas votre mise en page visuelle. Les lecteurs d’écran fonctionnent en accédant à l’arbre d’accessibilité, une représentation structurée de la page que le navigateur construit à partir du DOM HTML. Le navigateur expose cet arbre via des API d’accessibilité spécifiques à la plateforme : UI Automation sur Windows, NSAccessibility sur macOS et AccessibilityService sur Android. Le lecteur d’écran interroge cette API, reçoit des informations sémantiques sur chaque élément et les convertit en sortie vocale ou braille.

Cela a une implication cruciale : ce que vous voyez à l’écran et ce qu’un lecteur d’écran perçoit peuvent être radicalement différents. Si votre design visuel utilise un <div> stylé pour ressembler à un bouton, un lecteur d’écran ne l’annoncera pas comme un bouton — parce qu’il n’a aucun rôle de bouton dans l’arbre d’accessibilité. Le lecteur d’écran annonce ce que dit le code, pas ce que montrent les pixels. Les éléments HTML sémantiques comme <button>, <nav>, <h1> et <form> portent des rôles intégrés qui sont automatiquement exposés à l’arbre d’accessibilité. Lorsque les développeurs contournent ces éléments au profit d’éléments génériques bricolés avec des rôles ARIA, ils créent une complexité inutile et introduisent fréquemment de nouvelles erreurs.

Les lecteurs d’écran fournissent également un contexte qui n’est pas visible à l’écran. Lorsqu’un utilisateur rencontre une liste, le lecteur d’écran annonce combien d’éléments elle contient. Lorsqu’un tableau est atteint, il annonce le nombre de lignes et de colonnes. Quand le focus se déplace dans un champ de formulaire, il lit l’étiquette du champ, son type et son état actuel. Ces métadonnées contextuelles dépendent entièrement d’un HTML bien structuré et sémantique. Si vous les supprimez, vous supprimez la capacité de l’utilisateur à comprendre ce à quoi il a affaire.

Les principaux lecteurs d’écran : JAWS, NVDA, VoiceOver et TalkBack

Le marché des lecteurs d’écran est dominé par une poignée d’outils, chacun avec des caractéristiques distinctes. Comprendre sur quels outils vos utilisateurs s’appuient probablement informe directement la manière dont vous devez tester votre site.

JAWS (Job Access With Speech), développé par Freedom Scientific et publié pour la première fois en 1995, est depuis longtemps considéré comme la référence de l’industrie, en particulier pour un usage en entreprise. Dans l’enquête WebAIM 2024, JAWS était le lecteur d’écran principal pour environ 41 % des répondants. C’est un produit commercial avec des coûts de licence allant de 90 $ à plus de 1 400 $ par an. JAWS offre une personnalisation étendue, une compatibilité robuste avec des flux de travail complexes dans Microsoft Office et des applications professionnelles, et un « mode navigation » (Browse Mode) qui transforme la page en un environnement linéaire navigable permettant aux utilisateurs de sauter entre titres, repères et champs de formulaire à l’aide de raccourcis clavier intuitifs.

NVDA (NonVisual Desktop Access), développé par NV Access et introduit en 2006, est un lecteur d’écran gratuit et open source pour Windows. Il était le lecteur d’écran principal pour environ 38 % des répondants à l’enquête WebAIM en 2024 — un chiffre presque identique à celui de JAWS. NVDA a gagné une popularité significative grâce à son modèle gratuit, ses mises à jour fréquentes et ses performances robustes. En 2025, NVDA a introduit une gestion améliorée du focus dans les applications monopage, aidant les utilisateurs à comprendre quand le contenu a changé et où le focus s’est déplacé. Son association de navigateur recommandée est Firefox, bien que la prise en charge de Chrome soit également solide.

VoiceOver est le lecteur d’écran intégré d’Apple, disponible sur macOS, iOS et iPadOS — aucune installation requise. Sur ordinateur, il utilise des raccourcis clavier avec le modificateur VO (Control + Option), tandis que sur iOS il repose sur des gestes tactiles tels que le balayage, le double-tap et le rotor. Sur les appareils mobiles, VoiceOver est le lecteur d’écran le plus utilisé, 70,6 % des utilisateurs de lecteurs d’écran mobiles s’y fiant. Il fonctionne mieux associé à Safari, qui est le seul navigateur exposant pleinement les API d’accessibilité de macOS/iOS à VoiceOver.

TalkBack est le lecteur d’écran intégré d’Android, offrant des retours vocaux et des vibrations pour aider les utilisateurs à naviguer sur leurs appareils. C’est l’outil standard pour les tests mobiles sur Android et il s’associe le mieux avec Chrome. Windows est également livré avec Narrator, un lecteur d’écran intégré qui s’est régulièrement amélioré mais qui manque encore de certaines fonctionnalités de JAWS et NVDA. Chacun de ces outils se comporte de manière légèrement différente — un modèle qui fonctionne correctement dans NVDA peut échouer dans JAWS — c’est pourquoi tester sur plusieurs lecteurs d’écran est essentiel pour tout programme d’accessibilité sérieux.

Comment les personnes aveugles naviguent réellement : le modèle mental qui change tout

Voici l’idée qui transforme le plus fondamentalement la manière dont les développeurs devraient penser leur travail : les utilisateurs de lecteurs d’écran ne lisent pas les pages linéairement de haut en bas. Ils utilisent un ensemble sophistiqué de stratégies de navigation pour parcourir et sauter dans le contenu efficacement, de la même manière qu’un utilisateur voyant survole visuellement la page. Si vous ne soutenez pas ces stratégies, même une page techniquement accessible devient une expérience épuisante et inutilisable.

La stratégie de navigation la plus répandue est la navigation par titres. L’utilisation des titres pour trouver des informations a augmenté au fil du temps et reste la méthode prédominante — 88,8 % des répondants à l’enquête trouvent les niveaux de titres très ou assez utiles. Les utilisateurs avancés sont beaucoup plus susceptibles de naviguer par titres que les débutants. En pratique, cela signifie qu’un utilisateur appuie sur la touche H dans JAWS ou NVDA pour passer au titre suivant sur la page, en parcourant rapidement la structure. Appuyer sur 1 à 6 permet de sauter directement à un titre de ce niveau. Si votre page n’a pas de titres, ou utilise des titres choisis pour leur taille visuelle plutôt que pour la structure du document, les personnes aveugles n’ont aucun repère entre lequel sauter — elles sont contraintes d’écouter toute la page depuis le début.

La deuxième grande stratégie est la navigation par repères. Les éléments de repère HTML5 — <main>, <nav>, <header>, <footer>, <aside> et <section> avec une étiquette — créent des régions nommées entre lesquelles les utilisateurs de lecteurs d’écran peuvent sauter à l’aide de leur rotor ou de raccourcis de repères. En 2025, l’adoption des repères ARIA a légèrement augmenté, portée par l’utilisation croissante de l’élément natif <main>, désormais présent sur 47 % des pages. Alors que 31,7 % des répondants indiquent utiliser toujours ou souvent les repères lorsqu’ils sont présents, seulement 3,7 % utilisent les repères comme méthode de navigation principale — ce qui suggère que les repères sont un outil secondaire, mais important pour l’orientation.

Les utilisateurs naviguent également par liens, champs de formulaire et boutons à l’aide de raccourcis à une touche, et ils affichent fréquemment des listes d’éléments — une boîte de dialogue montrant tous les titres, tous les liens ou tous les champs de formulaire de la page en une fois — pour parcourir et sauter directement à ce dont ils ont besoin. Ce comportement a d’énormes implications pour le texte des liens. Une liste de liens qui dit « Lire la suite, Lire la suite, Lire la suite » n’offre aucune valeur de navigation. Chaque lien et chaque bouton doit avoir un nom accessible descriptif et unique qui ait du sens hors contexte.

Sur mobile, le paradigme se déplace vers les gestes tactiles. Les utilisateurs de VoiceOver et TalkBack balayent vers la droite pour passer à l’élément suivant, effectuent un double-tap pour l’activer et utilisent des gestes de rotor pour changer de mode de navigation. La préférence pour l’utilisation d’applications mobiles a augmenté à 58 % en 2024, contre 51,8 % en 2021. Cela signifie que votre design responsive et votre accessibilité mobile ne sont pas des compléments optionnels — ce sont des cas d’usage principaux pour une grande partie des utilisateurs de lecteurs d’écran.

Les barrières les plus problématiques sur le web aujourd’hui

L’enquête de WebAIM a demandé aux répondants d’identifier les éléments les plus problématiques qu’ils rencontrent. Les résultats sont remarquablement cohérents sur plus d’une décennie d’enquêtes — et ils constituent une liste directe de ce que votre site doit réussir.

• Les CAPTCHA sont, de loin, la plainte principale. Les utilisateurs de lecteurs d’écran s’accordent à dire que les CAPTCHA sont l’élément le plus problématique depuis plus de quatorze ans d’affilée. L’utilisation d’un CAPTCHA traditionnel est évidemment problématique pour les personnes aveugles, car les lecteurs d’écran dont elles dépendent ne peuvent pas traiter l’image, les empêchant de découvrir l’information exigée par le formulaire. Même les CAPTCHA audio échouent pour de nombreux utilisateurs — la distorsion intentionnelle les rend inintelligibles. La recommandation pratique : utilisez autant que possible une vérification invisible basée sur le comportement, comme reCAPTCHA v3 ou des techniques de honeypot.
• Les éléments interactifs au comportement inattendu — menus, onglets, fenêtres de dialogue et widgets personnalisés qui ne suivent pas les modèles d’interaction clavier établis — arrivent juste derrière les CAPTCHA. Ces éléments sont souvent construits avec un excès d’attributs ARIA et présentent des comportements d’interaction irréguliers et des problèmes de compatibilité entre navigateurs et lecteurs d’écran.
• Les liens et boutons ambigus frustrent constamment les utilisateurs. Des expressions comme « cliquez ici », « en savoir plus » ou « lire la suite » n’offrent aucun indice sur la destination ou l’action lorsqu’elles sont entendues isolément dans une liste de liens.
• Les changements d’écran inattendus — mises à jour de contenu dynamiques qui se produisent sans avertissement — désorientent les personnes aveugles qui n’ont aucun indice visuel qu’un changement s’est produit. Cela est particulièrement aigu dans les applications monopage construites avec React, Vue ou Angular, où le contenu peut changer sans rechargement de page.
• Les hiérarchies de titres cassées sapent la stratégie de navigation principale de la plupart des utilisateurs avancés. Environ 39 % des sites web ont des hiérarchies de titres cassées, ce qui rend difficile pour les utilisateurs de lecteurs d’écran de naviguer correctement dans le contenu.
• Les textes alternatifs manquants ou inadéquats sur les images. Lorsque le texte alternatif est absent, un lecteur d’écran peut seulement indiquer la présence d’une image sans en décrire le contenu, ou — pire — lire un nom de fichier dénué de sens comme « IMG_4823.jpg ».

La majorité — 67 % — des utilisateurs de lecteurs d’écran ne contactent jamais ou rarement les propriétaires de sites web à propos des barrières. Ils partent simplement. Vous ne recevrez pas de plainte. Vous perdrez simplement un utilisateur.

Écrire du code que les lecteurs d’écran peuvent réellement interpréter

Comprendre les schémas de navigation des utilisateurs rend les exigences techniques beaucoup plus concrètes. Chaque décision que vous prenez dans le balisage et le JavaScript a une conséquence directe et audible pour les personnes aveugles. Voici les principes qui comptent le plus.

Le HTML sémantique est votre premier et plus puissant outil. La première règle d’ARIA stipule : « Si vous pouvez utiliser un élément ou un attribut HTML natif avec la sémantique et le comportement dont vous avez besoin déjà intégrés, au lieu de réutiliser un élément et d’ajouter un rôle, un état ou une propriété ARIA pour le rendre accessible, faites-le. » Des éléments comme <button>, <nav>, <header> et <form> sont livrés avec l’accessibilité intégrée. Utiliser des contrôles natifs garantit la compatibilité avec les navigateurs et les technologies d’assistance dès le départ, sans code supplémentaire.

ARIA est un complément, pas un substitut. ARIA (Accessible Rich Internet Applications) est un ensemble d’attributs HTML conçus pour combler les lacunes d’accessibilité lorsque le HTML seul ne peut pas exprimer la sémantique requise — par exemple, rendre un curseur personnalisé accessible, annoncer des changements de contenu dynamiques ou indiquer qu’un menu déroulant est actuellement développé. Le danger réside dans le mauvais usage. Les pages d’accueil avec ARIA présentent en moyenne plus de deux fois plus d’erreurs d’accessibilité que les pages sans ARIA. Plus d’ARIA ne signifie pas plus accessible — cela signifie souvent plus d’erreurs. Les pages qui utilisaient ARIA de manière incorrecte présentaient 70 % d’erreurs détectables de plus que celles qui ne l’utilisaient pas. Utilisez-le de manière chirurgicale, là où aucun élément natif ne peut faire le travail.

L’exemple de code suivant illustre la différence entre un bouton personnalisé inaccessible et un bouton correctement accessible :

<!-- Inaccessible: a div with click handler, no role, no keyboard support -->
<div class='btn' onclick='submitForm()'>Submit</div>

<!-- Accessible: native button with built-in role, keyboard support, and focus -->
<button type='submit'>Submit</button>

<!-- If you must use a non-button element, add role, tabindex, and keyboard event -->
<div role='button' tabindex='0'
     aria-label='Submit the registration form'
     onkeydown='handleKey(event)'
     onclick='submitForm()'>
  Submit
</div>

Les régions ARIA live sont le mécanisme correct pour annoncer les changements de contenu dynamiques. Lorsque votre page met à jour du contenu sans rechargement complet — un message de validation de formulaire, un total de panier, une notification — ce changement est silencieux pour un utilisateur de lecteur d’écran à moins que vous n’utilisiez une région live. L’attribut aria-live='polite' indique au lecteur d’écran d’annoncer le changement après la fin de l’activité en cours de l’utilisateur, tandis que aria-live='assertive' interrompt immédiatement — utilisez ce dernier avec parcimonie, uniquement pour les alertes urgentes. En 2025, environ 33 % des sites utilisent l’attribut aria-live, soit 4 % de plus qu’en 2024, mais l’adoption est encore bien trop faible au regard du nombre d’interfaces dynamiques déployées.

La gestion du focus dans les composants interactifs — boîtes de dialogue modales, menus déroulants, accordéons — doit être gérée explicitement. Lorsqu’une modale s’ouvre, le focus doit se déplacer à l’intérieur. Lorsqu’elle se ferme, le focus doit revenir à l’élément qui l’a déclenchée. Une personne utilisant un lecteur d’écran qui ouvre une modale et trouve le focus toujours sur le bouton derrière celle-ci est, en pratique, exclue du contenu de la boîte de dialogue.

Tester votre site avec un lecteur d’écran

Les analyseurs automatiques d’accessibilité sont utiles mais limités. Les outils automatisés détectent 30 à 40 % des violations WCAG, mais les tests avec de vraies technologies d’assistance révèlent comment les utilisateurs vivent réellement votre site — contexte manquant, navigation confuse et interactions qui ne fonctionnent tout simplement pas. Aucun analyseur ne vous dira que le titre de votre modale n’a aucun sens sans le contexte visuel qui l’entoure, ou que votre menu déroulant personnalisé annonce son état de manière incorrecte dans une combinaison navigateur–lecteur d’écran mais pas dans une autre.

Le point de départ pratique pour la plupart des équipes est NVDA avec Firefox — gratuit, largement utilisé et efficace pour détecter la grande majorité des problèmes courants. Ajoutez VoiceOver avec Safari pour couvrir les utilisateurs macOS et iOS. Pour les contextes d’entreprise ou les clients ayant de fortes exigences de conformité, incluez JAWS avec Chrome ou Edge. Chaque lecteur d’écran fonctionne mieux avec une association de navigateur spécifique ; utiliser la mauvaise combinaison peut produire des résultats de test trompeurs.

Lors des tests, adoptez les schémas de navigation que les vrais utilisateurs emploient. N’utilisez pas de souris. Naviguez par titres à l’aide de la touche H. Affichez la liste des liens et vérifiez que chaque lien a du sens hors contexte. Parcourez les champs de formulaire avec la touche Tab et vérifiez que chaque étiquette est correctement annoncée. Ouvrez les boîtes de dialogue modales et vérifiez que le focus s’y déplace. Remplissez des formulaires et soumettez-les, en écoutant chaque message de validation. Éteignez votre écran et essayez de réaliser une tâche utilisateur représentative du début à la fin — cette expérience, aussi inconfortable soit-elle pour un testeur voyant, est la réalité quotidienne de vos utilisateurs aveugles.

Il est également important de tester avec de vraies technologies d’assistance plutôt qu’avec des émulateurs ou simulateurs de navigateur. Les panneaux d’accessibilité des outils de développement des navigateurs vous montrent l’arbre d’accessibilité, ce qui est utile pour le débogage, mais ils ne reproduisent pas l’expérience auditive ni ne révèlent les particularités d’interaction qui n’apparaissent qu’avec un véritable logiciel de lecteur d’écran.

Le cas commercial et juridique que vous ne pouvez pas ignorer

Si le cas moral en faveur de l’accessibilité doit être renforcé par la réalité commerciale, les chiffres sont éloquents. Il y a environ 7 millions de personnes ayant une déficience visuelle aux États-Unis seulement, représentant une base de consommateurs significative. À l’échelle mondiale, 26 % des adultes américains ont un handicap, représentant une opportunité de marché estimée à 13 000 milliards de dollars. Lorsque la conception inaccessible exclut les personnes aveugles de votre site, vous ne manquez pas seulement à une obligation morale — vous refusez des clients et exposez votre organisation à un risque juridique.

WCAG 2.2 est désormais la norme juridique de référence dans des milliers de poursuites liées à l’ADA, et l’European Accessibility Act, qui est pleinement entré en vigueur pour les entreprises du secteur privé en juin 2025, étend les exigences de conformité dans toute l’UE. La majorité des utilisateurs de lecteurs d’écran ne contactent jamais les propriétaires de sites web à propos des barrières — ils partent simplement et emmènent leur activité ailleurs. Les 67 % d’utilisateurs qui ne signalent jamais les problèmes ne sont pas satisfaits ; ils sont découragés. Intégrer la compatibilité avec les lecteurs d’écran dans votre processus de développement dès le départ évite des remédiations coûteuses, réduit l’exposition juridique et ouvre vos produits à un public qui recherche activement des expériences numériques qu’il peut réellement utiliser.

Points clés à retenir

• Les lecteurs d’écran naviguent dans la structure, pas dans le visuel. Ils interrogent l’arbre d’accessibilité du navigateur via les API d’accessibilité de la plateforme. Le HTML sémantique — titres corrects, repères, contrôles natifs — est l’investissement le plus efficace que vous puissiez faire pour la compatibilité avec les lecteurs d’écran.
• Les personnes aveugles naviguent par titres, repères et listes d’éléments — pas de manière linéaire. Plus de 88 % des utilisateurs de lecteurs d’écran trouvent les niveaux de titres très ou assez utiles pour la navigation. Une hiérarchie de titres cassée ou manquante est l’une des défaillances d’accessibilité les plus courantes et les plus dommageables sur le web.
• ARIA amplifie à la fois le bon et le mauvais balisage. Les pages avec ARIA présentent en moyenne plus de deux fois plus d’erreurs d’accessibilité que les pages sans. Utilisez ARIA uniquement lorsque le HTML natif ne peut pas exprimer la sémantique requise, et testez toujours avec de vraies technologies d’assistance après l’avoir implémenté.
• Les CAPTCHA, les liens ambigus et les changements de contenu dynamiques non annoncés sont les principales barrières réelles. Remplacer les CAPTCHA visuels par une vérification basée sur le comportement, rédiger des textes de liens et de boutons descriptifs et implémenter des régions ARIA live pour les mises à jour dynamiques aura un impact immédiat et mesurable sur l’utilisabilité pour les personnes aveugles.
• Testez avec de vrais lecteurs d’écran sur plusieurs associations navigateur–lecteur. Les analyseurs automatisés ne détectent que 30 à 40 % des violations WCAG. NVDA avec Firefox et VoiceOver avec Safari couvrent la majorité de votre base d’utilisateurs à coût nul, et l’expérience de navigation sur votre site sans souris révèle des problèmes qu’aucun outil automatisé ne peut mettre en évidence.