Chapitre 5.1 — Comment ça marche

⏱️ TL;DR — Un lecteur d’écran restitue la page en synthèse vocale ou sur un afficheur braille. Il ne lit pas ton écran de haut en bas comme un humain : il parcourt une représentation linéarisée de la page dans deux modes. En mode navigation (parcours), l’utilisateur lit et saute d’élément en élément (titre suivant, lien suivant, landmark suivant) grâce à des raccourcis. En mode formulaire (focus), il tape dans les champs et interagit. Les principaux lecteurs — NVDA, JAWS, VoiceOver, TalkBack, Orca — se couplent chacun à un navigateur recommandé. Comprendre ces deux modes, c’est comprendre pourquoi ta structure HTML compte autant.

🎯 Objectifs

• Décrire comment un lecteur d’écran restitue l’information (voix, braille) et à quelle vitesse.
• Distinguer le mode navigation (parcours du buffer) du mode formulaire (focus/interaction).
• Citer les raccourcis de navigation structurelle (par titres, landmarks, liens, formulaires).
• Nommer les principaux lecteurs et leur navigateur recommandé.
• En déduire ce que ça implique pour ton code.

Restituer la page : voix et braille

Un lecteur d’écran (screen reader) est un logiciel qui lit à voix haute — via une synthèse vocale (Text-To-Speech) — le contenu et la sémantique de l’interface, ou l’envoie à un afficheur braille (une barre de picots rafraîchissables sous les doigts). L’utilisateur règle la vitesse de la voix, souvent très élevée pour un habitué : 300, 400 mots/minute, parfois plus. À cette cadence, chaque annonce inutile ou mal formulée coûte cher.

Ce qu’il annonce, c’est le triptyque nom / rôle / valeur de chaque élément : « Se souvenir de moi, case à cocher, non cochée », « Envoyer, bouton », « Tableau de bord, titre de niveau 1 ». Il ne décrit pas ton design (couleurs, position, ombres) : il décrit ce que ton HTML déclare. On étudie l’origine de ces annonces au chapitre 5.3.

♿ Côté utilisateur — Imagine « lire » cette page à l’oreille, sans jamais la voir. Tu n’as pas de vue d’ensemble : tu reçois un flux linéaire, mot après mot. Pour ne pas tout écouter, tu sautes de titre en titre pour te faire une carte mentale, puis tu plonges dans la section voulue. Une page bien structurée s’explore en quelques secondes ; une « soupe de <div> » sans titres ni landmarks t’oblige à écouter tout, linéairement, comme un livre audio sans chapitres.

Les deux modes de lecture

C’est le concept à retenir de ce chapitre. Sur une page web, un lecteur d’écran de bureau (NVDA, JAWS, VoiceOver) fonctionne dans deux modes que l’utilisateur bascule en permanence.

Mode navigation (parcours / browse mode)

Le mode par défaut pour lire une page. Le lecteur construit une copie linéarisée de la page — un tampon virtuel (virtual buffer, aussi appelé mode « parcours ») — que l’utilisateur explore librement :

• Lecture linéaire : flèche bas pour avancer élément par élément, du début à la fin.
• Navigation structurelle : des raccourcis à une touche pour sauter d’un type d’élément au suivant. Sur NVDA/JAWS par exemple : H pour le titre suivant, D pour le landmark (région) suivant, K pour le lien suivant, F pour le champ de formulaire suivant, T pour le tableau suivant, B pour le bouton suivant.
• Listes d’éléments : ouvrir la liste de tous les titres, tous les liens ou toutes les landmarks pour naviguer d’un coup.

Dans ce mode, les touches (H, K, F…) sont captées par le lecteur, pas envoyées à la page. C’est ce qui rend la lecture si rapide — mais ça implique que ta structure sémantique existe vraiment (des <h2>, un <nav>, un <main>), sinon il n’y a rien à sauter.

Mode formulaire (focus / focus mode)

Dès que l’utilisateur atteint un champ de saisie (<input>, <textarea>, un <select>), le lecteur bascule — automatiquement ou à la demande — en mode formulaire. Là, les frappes sont transmises à la page : taper « H » écrit la lettre H dans le champ au lieu de sauter au titre suivant. C’est le mode de l’interaction : remplir, cocher, choisir dans une liste, actionner un widget.

⚠️ Piège — Un widget custom (menu, onglets, combobox en <div>) sur lequel l’utilisateur reste en mode navigation ne recevra jamais tes raccourcis clavier : le lecteur intercepte les touches avant ton JavaScript. C’est pour ça que les composants riches doivent exposer le bon rôle ARIA — il fait basculer le lecteur en mode application/formulaire pour que tes interactions clavier passent. On y revient en Partie 6.

Panorama des lecteurs d’écran

Chaque lecteur se marie de préférence avec un navigateur. Utilise ces couples pour tester ce que vivent réellement tes utilisateurs.

NVDA et JAWS dominent sur Windows en entreprise ; commence par NVDA, gratuit et fidèle au comportement de JAWS. VoiceOver est incontournable pour tester l’expérience Apple, en particulier le mobile iOS. TalkBack couvre Android. On ne teste jamais « en général » : un composant peut très bien fonctionner sous NVDA+Firefox et trébucher sous VoiceOver+Safari, car chaque moteur interprète l’arbre d’accessibilité à sa manière.

🧭 Sur A11yLearn — Le tableau de bord d’A11yLearn est notre terrain d’essai. À l’oreille, un apprenant aveugle ne « voit » pas la grille de cartes joliment alignée : il entend une suite de titres et de liens. S’il peut faire H, H, H pour survoler « Mes cours », « Ma progression », « Prochaine session » puis D pour sauter à la navigation principale, il se repère en quelques secondes. Sans cette structure, il subit la page en lecture linéaire. Notre objectif au fil du cours : que chaque écran d’A11yLearn s’explore aussi vite à l’oreille qu’à l’œil.

Ce que ça implique pour le dev

Trois conséquences directes sur ta façon de coder :

1. La structure sémantique est de la navigation. Tes <h1>–<h6>, <nav>, <main>, <ul> ne sont pas décoratifs : ce sont les rails sur lesquels l’utilisateur saute. Pas de titres → pas de raccourcis → page subie.
2. L’ordre du DOM est l’ordre de lecture. Le tampon virtuel suit l’ordre du HTML, pas ta mise en page CSS. Un bloc placé « à droite » visuellement mais « avant » dans le DOM sera lu en premier.
3. Les widgets custom doivent déclarer leur rôle. Sinon le lecteur reste en mode navigation et avale tes raccourcis clavier. Le bon rôle (natif de préférence, ARIA sinon) fait basculer les modes correctement.

✏️ Exercices

Exercice 1 — Navigation à l’aveugle. Un utilisateur arrive sur une page d’A11yLearn et veut atteindre directement le formulaire de connexion, plus bas. Décris deux façons pour lui d’y arriver sans lire toute la page, et dis de quoi ton HTML doit disposer pour que ça marche.

Exercice 2 — Le bon mode. Un dev se plaint : « Mon menu déroulant custom en <div> ne réagit pas quand l’utilisateur de lecteur d’écran appuie sur les flèches, alors qu’au clavier normal ça marche. » Explique la cause probable en termes de modes.

🧠 Quiz de révision

Chapitre suivant : L’arbre d’accessibilité — comment le navigateur transforme ton DOM en la structure que consomment les technologies d’assistance, et comment l’inspecter.