Partie 5 — Lecteurs d’écran & arbre d’accessibilité

⏱️ TL;DR — Pour coder accessible, il faut comprendre ce que « voit » un lecteur d’écran — c’est-à-dire l’arbre d’accessibilité, pas tes pixels. Cette partie démystifie le fonctionnement d’un lecteur d’écran (synthèse vocale, braille, modes de lecture), l’arbre d’accessibilité construit à partir de ton DOM, le triptyque nom / rôle / valeur qui structure toute l’a11y, et t’apprend à tester avec un vrai lecteur d’écran plutôt qu’à deviner. Après ça, tu ne codes plus « à l’aveugle » : tu sais exactement ce que ton HTML expose.

Le problème qu’on résout

Un dev qui n’a jamais lancé de lecteur d’écran code pour un utilisateur qu’il n’imagine pas. Il ajoute un aria-label « au cas où », met un alt vide sans savoir pourquoi, et se demande pourquoi son composant « pourtant stylé correctement » reste inutilisable. La cause est toujours la même : il raisonne sur les pixels alors que la technologie d’assistance, elle, ne consomme que l’arbre d’accessibilité. Cette partie répare ça. Tu vas comprendre comment le navigateur transforme ton DOM en arbre, ce qui y entre ou en sort, comment chaque nœud reçoit un nom/rôle/valeur, et surtout comment inspecter et écouter le résultat. C’est le pont entre « je crois que c’est accessible » et « je l’ai vérifié ».

Ce que tu sauras faire à la fin de cette partie

• Expliquer comment un lecteur d’écran restitue une page (synthèse vocale, braille) et ses modes de lecture (navigation vs formulaire).
• Nommer les principaux lecteurs (NVDA, JAWS, VoiceOver, TalkBack, Orca) et leur navigateur recommandé.
• Décrire l’arbre d’accessibilité et l’inspecter dans les DevTools.
• Maîtriser le modèle nom / rôle / valeur (critère 4.1.2) et le calcul du nom accessible.
• Lancer un lecteur d’écran pour tester un parcours, et masquer du contenu avec la bonne technique (display:none, sr-only, aria-hidden).

Les chapitres

On commence : Comment ça marche.