Comment fonctionne un lecteur d'écran (et pourquoi ça change tout)

Une page n'est pas lue de haut en bas

L'idée répandue veut qu'un lecteur d'écran lise la page du début à la fin. C'est faux, et c'est le malentendu qui produit le plus de mauvais choix techniques. Un utilisateur expérimenté navigue : il saute de titre en titre, appelle la liste des liens, passe d'un point de repère à l'autre.

Le lecteur d'écran ne lit pas le HTML : il exploite l'arbre d'accessibilité construit par le navigateur, où chaque élément porte un rôle, un nom et un état.

Ce que l'utilisateur entend

Pour un lien, la restitution suit toujours la même structure : nom, rôle, état. « Nous contacter, lien » ; « Accepter les conditions, case à cocher, non cochée ». D'où découlent directement plusieurs critères RGAA :

• un bouton sans intitulé s'annonce « bouton » — sans aucune indication de sa fonction ;
• un titre h2 utilisé pour sa taille casse la navigation par titres ;
• une image sans alternative est annoncée par son nom de fichier ;
• un div cliquable n'a aucun rôle : il n'existe pas dans la liste des éléments actionnables.

> Le test des liens hors contexte — Appelez la liste des liens d'une page : si elle contient six fois « En savoir plus », elle est inutilisable. L'intitulé doit se suffire à lui-même, sans la phrase qui l'entoure.

Les logiciels en présence

NVDA (gratuit, Windows) et JAWS (payant, très répandu en entreprise) dominent sur poste fixe ; VoiceOver est intégré à iOS et macOS, TalkBack à Android. Ils ne restituent pas tous exactement pareil : un audit sérieux en teste au moins deux.

Pourquoi l'essayer

Une demi-heure passée à parcourir son propre site avec NVDA enseigne plus que n'importe quelle documentation. Les critères cessent d'être des règles abstraites : ils deviennent des explications de ce qu'on vient d'entendre.

---

À lire aussi

• Les 106 critères du RGAA expliqués
• Handicap et web en France : les chiffres
• RGAA et WCAG : quelle différence ?