Histoire des technologies des lecteurs d’écran

Un lecteur d’écran est une technologie d’assistance au service des personnes aveugles consistant à rendre accessible une interface informatique au travers d’une synthèse vocale et / ou d’un afficheur Braille. Un lecteur d’écran n’est pas une synthèse vocale, une synthèse vocale n’est pas un lecteur d’écran. L’un exploitant l’autre, nous nous intéresserons à ce qui se passe sous le capot d’un lecteur d’écran mais nous n’aborderons pas la manière dont est généré de la parole.

Aujourd’hui, il existe des lecteurs d’écran sur la plupart des systèmes d’exploitation grand publics, qu’ils soient installés sur un ordinateur ou un appareil mobile.

Fonctionnement général d’un lecteur d’écran

Un lecteur d’écran restitue l’information de manière automatique et structurée. Il offre des commandes supplémentaires au système d’exploitation pour explorer tout ou partie de l’écran, affiner ses paramètres, spécifier des déclenchements liés à certains événements etc.

Aujourd’hui, ces commandes sont accessibles par des raccourcis clavier propres au lecteur d’écran, mais certains lecteurs d’écran étaient distribués avec un pavé numérique dédié à leurs commandes.

Beaucoup de lecteurs d’écran mobilisent le pavé numérique et surchargent la touche insertion ou la touche verrouillage majuscule en combinaison d’autres touches pour interagir avec eux. D’autres utilisaient la séquence de touches contrôle suivie d’une autre touche évitant ainsi de condamner le pavé numérique.

Du mode texte au mode graphique

Le mode texte, en opposition au mode graphique, est une interface comme son nom l’indique, permettant de n’afficher que du texte. Elle a précédé au mode graphique, plus abordable désormais aux non informaticiens.

L’arrivée du mode graphique a beaucoup inquiété les utilisateurs aveugles car son accessibilité était, et est encore par beaucoup d’aspect, loin d’être évidente. C’est cette problématique qui est au cœur de notre sujet.

Le mode texte

On connaît les systèmes en mode texte comme l’ont été MS-DOS, OS/2 ou encore Unix. On interagit avec ces interfaces essentiellement en tapant des commandes et celles-ci répondent par des lignes de texte.

Imaginons une feuille a carreaux, composée de 25 lignes sur 80 colonnes. Chaque carreau possède une coordonnée. Les caractères inscrits à l’écran et stockés dans le tampon d’affichage sont placés chacun dans un carreau. Un caractère est spécifié par deux nombres qui représentent son codeASCII et son attribut couleurs. Par exemple, si l’on veut afficher la lettre »I » majuscule en blanc sur bleu, les propriétés du caractères seront <73, 31>.

Cette représentation de l’’information est exactement ce qu’exploite un lecteur d’écran en mode texte en lisant le tampon d’affichage.

Si l’exploitation de l’information est relativement simple, automatiser sa restitution ne l’est pas toujours. C’est pourquoi pour chaque logiciel, des règles d’actions devaient être écrites afin que le lecteur d’écran sache quelle zone de la fenêtre suivre et quelles étaient les attributs couleurs des items sélectionnés dans une fenêtre construites en ncurses par exemple.

Le mode graphique, un vrai défi

Contrairement au mode texte, l’information n’est pas représentée dans une grille aux dimensions prédéterminées et les caractères sont dessinés par des pixels qui sont des points de couleur. Par exemple, un « I » en blanc sur bleu est composé d’un mélange d’environ 128 pixels bleus et blancs dont le blanc représente la lettre « I ». Aucun code ASCII n’est contenu dans le tampon d’affichage.

Alors comment rendre cette information exploitable par un lecteur d’écran ?

Une des solutions serait d’effectuer de la reconnaissance de caractères du tampon d’affichage. Si cette solution pourrait être une réponse à un affichage statique, elle ne l’est en revanche pas pour un affichage dynamique.

Off-screen-model

Les premiers lecteurs d’écran pour interfaces graphiques se sont appuyés sur la technologie dite « off-screen-model » (OSM), introduite par Berkeley system, lors de la conception d’Outspoken sous MacIntosh en 1989, le premier lecteur d’écran pour interface graphique.

Le principe de l’OSM est d’intercepter tout ce qui est à destination du tampon d’affichage est de stocker dans une base de données appelée off-screen-model les informations pertinentes. Cette structure de données contient du texte, sa position, sa couleur, sa police et les coordonnées de la fenêtre dans laquelle il est rattaché.

Une fois ce off-screen-model obtenu, il est plus aisé pour un lecteur d’écran d’offrir une représentation de l’information identique au mode texte.

Complexité des barres d’état

Les barres d’état donnent des informations contextuelles sur les actions effectuées pour indiquer qu’un événement a réussi ou échoué, etc. Il est important que ces informations soient lues automatiquement.

Si en mode texte, cette barre d’état se situe dans une zone de l’écran à valeur absolue, il est aisé d’indiquer au lecteur d’écran sa position et d’y associer une action à un événement en relation avec celle-ci. Par exemple, prononcer automatiquement le contenu de cette barre si celui-ci change.

En mode graphique, la position de cette barre d’état est relative. Dans un traitement de texte par exemple, si habituellement elle se situe en bas de l’écran, elle peut ne pas exister tant qu’aucun message n’est à afficher et une partie du texte que l’on est en train d’éditer peut très bien la remplacer.

Par conséquent, le lecteur d’écran s’appuie sur l’arborescence de la fenêtre pour connaître la position de la barre d’état.

Complexité du curseur d’application

Le curseur d’application, ou focus, est une notion abstraite pour qui lit sur un écran. Mais pour un lecteur d’écran, elle est indispensable. Le focus permet à l’utilisateur aveugle de se situer dans une application : quel item est sélectionné dans un menu ? où sera inséré le caractère tapé au clavier ?

En mode texte, la position du focus est stockée dans un registre matériel de l’affichage. Il suffit alors au lecteur d’écran de consulter ce registre.

En mode graphique, ce focus peut prendre bien des formes : une ligne, une boîte ou encore un changement de couleur. Aucun développeur de lecteur d’écran ne peut prévoir comment un logiciel a décidé de symboliser celui-ci.

Le bus d’accessibilité

Pour uniformiser tout cela, les développeurs de lecteurs d’écran ont abandonné le off-screen-model et, en lien avec les systèmes d’exploitation, ont conçu des protocoles standards permettant à n’importe quel logiciel d’être en théorie accessible. On l’appelle le bus d’accessibilité. Sous Windows, il s’agit d’IAccessible2 ou UI Automation, d’ATS-SPI sous GNU/Linux. Un toolkit de développement graphique comme GTK ou Qt communique toutes ses propriétés à un bus d’accessibilité : titre de la fenêtre, ses éléments, l’état de chacun de ses éléments, les événements survenant au cours de l’utilisation du logiciel etc. De l’autre côté, le lecteur d’écran récupère ses informations et les traite pour être communiquées de manière pertinente à l’utilisateur.

Le bus d’accessibilité peut s’étendre à d’autres utilisation que les lecteurs d’écran. Par exemple, il est utile pour l’automatisation des tests. En effet, si le bus d’accessibilité sert à récupérer de l’information sur les fenêtres, il peut également servir à envoyer des instructions à celles-ci.

Depuis les années 80, les technologies d’accessibilité ont beaucoup évolué. Cependant, le monde n’étant pas parfait, il existe toujours des toolkits graphiques n’étant pas compatibles avec le bus d’accessibilité et des logiciels comportant des interfaces dont les boutons n’ont pas de labels textuels, des éléments dont le tab-index n’est pas corrélé avec l’ordre à l’écran etc.