Un lecteur d’écran ne lit pas une page web : voici ce qu’il fait réellement
Quand on parle d’accessibilité numérique, une phrase revient souvent :
« Il faut rendre le site lisible par les lecteurs d’écran. »
Cette phrase semble logique.
Après tout, un lecteur d’écran porte bien son nom.
On imagine facilement un logiciel qui parcourt la page, lit les textes visibles et les vocalise.
Mais cette représentation est incomplète.
Un lecteur d’écran ne lit pas réellement une page web comme un humain regarde un écran.
Il ne voit pas :
- les couleurs
- les espaces
- les alignements
- les tailles de caractères
- les éléments qui semblent importants visuellement
Il ne comprend pas non plus une page comme nous la comprenons instinctivement.
Il travaille à partir d’une autre représentation de l’interface.
Une représentation construite par le navigateur à partir du code, de la structure HTML et des informations d’accessibilité disponibles.
Comprendre cela change complètement la manière de concevoir des interfaces accessibles.
Une page web possède plusieurs réalités
Lorsqu’un designer crée une page, il pense généralement à son apparence.
Il regarde :
- la hiérarchie visuelle
- la position des éléments
- les couleurs
- les interactions
C’est la réalité visible.
Mais une page web possède aussi une réalité technique.
Le navigateur interprète le code HTML et construit une structure interne.
Cette structure permet notamment aux technologies d’assistance de comprendre :
- ce qui est un titre
- ce qui est un bouton
- ce qui est un lien
- ce qui est un champ de formulaire
- ce qui est une liste
- ce qui est une zone de navigation
Le lecteur d’écran ne consulte donc pas directement les pixels affichés.
Il consulte une interprétation de la page.
Imaginez visiter une ville avec une carte différente
Pour comprendre le fonctionnement d’un lecteur d’écran, une comparaison peut aider.
Imaginez que vous arrivez dans une ville inconnue.
Une personne voyante pourrait se repérer en regardant :
- les bâtiments
- les panneaux
- les couleurs
- les vitrines
- les formes des rues
Mais imaginez maintenant que vous devez utiliser une carte spéciale.
Cette carte ne montre pas les bâtiments.
Elle indique plutôt :
- ici se trouve un lieu important
- ici commence une rue principale
- ici il y a une intersection
- ici se trouve une entrée
Cette carte ne ressemble pas exactement à la ville.
Mais elle permet de la comprendre autrement.
Le lecteur d’écran fonctionne un peu de cette manière.
Il exploite une représentation structurée de l’interface.
Le navigateur analyse le HTML
Avant même que le lecteur d’écran intervienne, le navigateur fait une grande partie du travail.
Il transforme le code HTML en une structure exploitable.
Prenons un exemple simple :
<h1>
Mon espace client
</h1>
<button>
Télécharger ma facture
</button>
Le navigateur comprend naturellement :
- ceci est un titre principal
- ceci est un bouton interactif
Ces informations sont ensuite disponibles pour les technologies d’assistance.
À l’inverse :
<div>
Télécharger ma facture
</div>
peut sembler identique visuellement après l’ajout de CSS.
Mais techniquement, le navigateur voit seulement :
« un élément générique contenant du texte ».
Il ne sait pas automatiquement qu’il s’agit d’une action.
C’est une différence fondamentale.
Le lecteur d’écran navigue
Une idée reçue est d’imaginer un utilisateur de lecteur d’écran qui attendrait patiemment que toute la page soit lue du début à la fin.
Dans la pratique, c’est rarement ainsi.
Les utilisateurs expérimentés naviguent.
Ils utilisent des raccourcis pour aller directement vers certains éléments :
- les titres
- les liens
- les boutons
- les champs de formulaire
- les tableaux
- les zones importantes
C’est comparable à une personne voyante qui ne lit pas chaque mot d’une page.
Elle cherche rapidement :
« Où est le menu ? »
« Où commence l’article ? »
« Où est le bouton d’action ? »
Le lecteur d’écran permet également cette navigation rapide, à condition que la page soit correctement structurée.
Les titres ne servent pas uniquement à la mise en forme
Prenons un article ou une page complexe.
Un utilisateur voyant peut repérer rapidement les grandes sections grâce :
- à la taille des textes
- aux espaces
- à la mise en page
Un utilisateur avec un lecteur d’écran peut demander :
« Liste-moi les titres de cette page. »
Il obtient alors une sorte de plan.
Par exemple :
- Présentation du service
- Fonctionnalités
- Tarifs
- Questions fréquentes
- Contact
Cette structure permet de comprendre rapidement l’organisation de la page.
Mais si les titres sont uniquement créés avec du texte agrandi visuellement, cette carte disparaît.
L’information existe pour l’œil.
Elle n’existe pas pour la technologie d’assistance.
Les images silencieuses
On entend parfois :
« Les images sont un problème d’accessibilité. »
Ce n’est pas exactement vrai.
Une image peut parfaitement être accessible.
La question est :
quelle information transmet-elle ?
Prenons une image décorative.
Elle n’a pas besoin d’être annoncée.
En revanche, une image qui représente une information importante doit avoir une alternative.
Exemple :
Une image contenant un graphique montrant l’évolution des ventes.
Pour une personne voyante, le graphique transmet immédiatement une information.
Pour un utilisateur de lecteur d’écran, cette information n’existe pas sans alternative.
Le problème n’est donc pas l’image.
Le problème est l’information perdue.
Les formulaires comme meilleurs exemples
Les formulaires montrent très bien la différence entre voir une interface et la comprendre.
Un utilisateur voyant voit :
Adresse email
[________________]
Il associe naturellement le texte au champ.
Un lecteur d’écran, lui, a besoin que cette relation soit définie techniquement.
Sinon, il peut entendre :
« Champ de saisie vide »
Sans savoir ce qu’il doit saisir.
L’interface fonctionne visuellement.
Mais elle ne communique pas correctement.
Le rôle des attributs ARIA
ARIA intervient lorsque le HTML natif ne permet pas toujours d’exprimer certaines situations.
Il peut aider à transmettre :
- un état
- une relation
- un rôle particulier
Par exemple :
un menu qui s’ouvre
une fenêtre qui apparaît
un composant dynamique qui change
Mais ARIA ne transforme pas une mauvaise structure en bonne interface.
Un lecteur d’écran ne peut pas deviner l’intention du développeur.
Il utilise les informations qu’on lui fournit.
Si ces informations sont absentes ou incorrectes, il transmet une expérience erronée.
Ce que cela change dans la manière de concevoir
Comprendre le fonctionnement d’un lecteur d’écran amène une question différente.
Au lieu de demander :
« Est-ce que notre page est visible ? »
Il faut aussi demander :
« Est-ce que notre page est compréhensible sans voir l’écran ? »
Cela implique de penser :
- structure avant apparence
- sens avant décoration
- comportement avant animation
- information avant présentation
Ce sont d’ailleurs souvent de bonnes pratiques de conception, même en dehors de l’accessibilité.
Une interface doit avoir du sens, pas seulement une apparence
Une interface moderne est une combinaison entre plusieurs couches :
- ce que l’utilisateur voit
- ce que le navigateur comprend
- ce que les technologies d’assistance peuvent interpréter
Une interface réussie est une interface cohérente entre ces différentes réalités.
Le lecteur d’écran n’est pas un outil magique qui « lit » une page.
C’est un interprète.
Il transmet à l’utilisateur la structure et les informations que l’interface lui fournit.
Si la structure est claire, l’expérience peut être fluide.
Si l’interface repose uniquement sur l’apparence, une partie du contenu disparaît.
C’est pour cette raison que l’accessibilité commence rarement par les outils.
Elle commence par une question beaucoup plus simple :
Est-ce que l’interface a réellement du sens, même lorsqu’on ne peut pas la voir ?