Lecteurs d'écran : pourquoi un site « conforme » peut rester inutilisable au quotidien

Ce qu'un scan d'accessibilité valide n'est pas ce qu'un utilisateur entend

Un lecteur d'écran est un logiciel qui restitue vocalement (ou en braille) le contenu d'une page web pour les personnes aveugles ou malvoyantes. Michael Taylor, utilisateur quotidien de cette technologie, décrit sur le blog d'UsableNet un écart persistant entre la version visuelle d'un site et la version auditive avec laquelle il doit composer. Son constat : les barrières les plus fréquentes qu'il rencontre sont précisément celles qui passent sans encombre un scan automatisé ou un test réalisé par quelqu'un qui n'utilise pas de lecteur d'écran au quotidien.

Pour un responsable digital, le message est important : un rapport de conformité positif ne garantit pas une expérience utilisable. La conformité mesure la présence d'éléments techniques (descriptions, labels, structure), pas la logique de l'expérience vécue.

Deux exemples d'interfaces « propres » mais inutilisables

Les boutons superposés aux images produit

Sur les sites e-commerce, il est devenu courant de superposer des boutons d'action (« Partager », « Ajouter aux favoris ») directement sur la photo du produit. Visuellement, le rendu est moderne. Dans le code, tout peut être correct : description d'image présente, boutons bien étiquetés. Pourtant, en pratique, le lecteur d'écran de Michael Taylor traite souvent l'image comme un seul élément : impossible d'isoler un bouton pour l'activer. Ces boutons sont aussi ignorés quand il navigue en filtrant par type d'élément « bouton », car ils ne se trouvent pas dans le plan principal de la page.

Les résultats de recherche de vols annoncés dans le désordre

Deuxième exemple : sur un site de compagnie aérienne, les détails d'un vol sont présentés dans un bloc horizontal. Le lecteur d'écran annonce chaque information au fil de l'avancée du focus, dans un ordre souvent illogique. L'utilisateur ne peut plus déterminer quelles données vont ensemble ni ce qu'un chiffre signifie dans son contexte. Chaque texte est techniquement vocalisé, donc la page pourrait passer une inspection classique. Mais sans ordre ni logique, l'interface est inutilisable. Ce qui fonctionnerait : annoncer l'ensemble des détails d'un vol comme un bloc unique, avec de légères pauses entre les informations.

Ce que les scans automatisés ne peuvent pas détecter

Les outils de scan automatisé sont utiles, mais ils vérifient la présence d'éléments, pas leur pertinence. Deux cas concrets illustrent leurs limites :

• Des descriptions d'images inutiles mais « présentes » : sur un site marchand fréquemment utilisé par l'auteur, chaque image de la page d'accueil et des fiches produit porte la description « This Is A Graphic » (« Ceci est un graphique »). Elle n'apporte strictement aucune information, mais comme une description existe techniquement, le scan est satisfait.
• Un lecteur vidéo qui parle en continu : sur un autre site e-commerce, le lecteur vidéo est accessible « sur le papier » (lancement, contrôles, sortie du lecteur fonctionnent). Mais pendant la lecture, le lecteur d'écran annonce la progression du curseur de lecture chaque seconde, produisant un flux vocal ininterrompu qui couvre l'audio de la vidéo et rend le média impossible à consommer — y compris quand le focus est ailleurs sur la page. Les labels étant corrects, la page passe vraisemblablement un scan sans alerte.

En résumé, d'après cette expérience d'usage, les scans passent à côté de tout ce qui dépend de l'ordre, du regroupement et du temps : ils confirment qu'un texte ou un label existe, pas que l'information arrive dans un ordre compréhensible ni que la vocalisation n'entre pas en conflit avec le contenu.

Le facteur humain : tester comme les utilisateurs utilisent réellement

Selon Michael Taylor, ces problèmes auraient été détectés immédiatement par quiconque aurait essayé de regarder ces vidéos ou de comprendre ces images avec un lecteur d'écran activé. Mais le test manuel a lui aussi ses conditions de réussite : il ne suffit pas de savoir faire fonctionner le logiciel, il faut connaître les habitudes et les schémas de navigation des utilisateurs réels — comment ils parcourent une page, filtrent par type d'élément, se repèrent au son.

La navigation au clavier seule ne suffit pas non plus : ce que l'on voit n'est pas toujours ce que l'on entendra. Les blocages les plus sévères n'apparaissent que lorsque le lecteur d'écran est utilisé comme au quotidien.

Sa recommandation aux équipes qui testent : mettre de côté l'interface visuelle et parcourir le site sans aucun repère visuel. C'est ce qui se rapproche le plus de son quotidien, et selon lui, les designs et fonctionnalités problématiques se révèlent rapidement quand la page n'est plus que du son. Dernière pièce du dispositif : les testeurs utilisateurs réels, qui s'appuient chaque jour sur un lecteur d'écran et sont les plus à même de repérer les problèmes complexes qui échappent aux scans et aux sessions de test en laboratoire.

Ce que cela change pour une équipe digitale

Pour un responsable digital, plusieurs enseignements concrets se dégagent de ce témoignage :

• Un scan automatisé est un point de départ, pas une validation finale : il vérifie la conformité de surface, pas l'utilisabilité.
• Les choix de design modernes (contrôles superposés aux images, mises en page horizontales denses) peuvent créer des barrières invisibles pour les équipes voyantes, même avec un code techniquement propre.
• Les tests manuels gagnent en valeur quand ils sont réalisés lecteur d'écran activé, écran ignoré, et idéalement complétés par des tests avec des utilisateurs réels de technologies d'assistance.
• L'objectif à viser est un parcours complet de bout en bout, pensé selon les besoins et les habitudes de navigation des utilisateurs de lecteurs d'écran — pas une somme de critères validés page par page.