Vue d’ensemble

Les lecteurs d’écran sont des interfaces audio. Plutôt que d’afficher visuellement le contenu Web pour les utilisateurs dans une « fenêtre » à l’écran, les lecteurs d’écran convertissent le texte en voix de synthèse, afin que les utilisateurs puissent écouter le contenu. Les personnes voyantes ont généralement du mal à imaginer comment il est possible de n’utiliser qu’une interface audio pour consulter le Web tellement leur accès au monde est visuel. Il est vrai que l’expérience utilisateur d’une interface audio est complètement différente. Sans les lecteurs d’écran, les personnes aveugles auraient besoin d’autres personnes pour lire à haute voix le contenu pour elles. La technologie permet un accès indépendant à l’information pour une population qui sinon aurait toujours besoin de l’appui et l’assistance des autres.

Les lecteurs d’écran ne lisent pas le contenu Web tout à fait comme les êtres humains le font. La voix peut paraître un peu robotique et monotone. De plus, les utilisateurs les plus expérimentés accélèrent souvent la vitesse de la synthèse vocale jusqu’à un taux de lecture de 300 mots par minute ou plus, ce qui est trop rapide pour qu’un auditeur inexpérimenté puisse comprendre. En effet, lorsque des personnes écoutent un lecteur d’écran pour la première fois à un taux normal de lecture d’environ 180 mots par minute, elles se plaignent déjà qu’il lit trop rapidement. Il faut du temps pour s’habituer à écouter un lecteur d’écran, mais la chose intéressante est qu’une fois que les utilisateurs en prennent l’habitude, ils peuvent lire les contenus à une vitesse qui peut surprendre les personnes voyantes.

Deux des lecteurs d’écran les plus courants sont JAWS, de Freedom Scientific et Window Eyes de GW Micro. Ces logiciels peuvent non seulement lire les contenus Web, mais aussi les fonctionnalités du système d’exploitation Windows, les logiciels de traitement de texte et d’autres logiciels.

Linéarisation du contenu

Les interfaces audio lisent le contenu de manière linéaire aux utilisateurs, un objet après l’autre. Cela contraste avec la façon dont la plupart des personnes utilisent les interfaces visuelles. Les utilisateurs voyants peuvent analyser l’ensemble d’un écran presque instantanément, comprendre la présentation, le style artistique et les autres aspects macro du contenu. Les utilisateurs de lecteurs d’écran ne peuvent pas comprendre ces aspects macro aussi rapidement. La progression linéaire de la lecture du contenu du début à la fin de la page Web est un peu comme le menu des systèmes téléphoniques automatisés, qui ne révèlent pas toutes les options à la fois. Les utilisateurs doivent progresser par le biais de ces systèmes d’une manière graduée. L’idée que les interfaces audio présentent de manière linéarisée les contenus Web est un élément important qui devrait guider les développeurs Web au cours de l’ingénierie et du développement des sites Web.

Parcourir autrement les contenus

Malgré le fait que par nature les lecteurs d’écrans lisent de manière linéaire les contenus, il y a des moyens pour les utilisateurs de lecteurs d’écrans de parcourir autrement les contenus.

Prendre en compte les différences entre les lecteurs d’écrans

Les lecteurs d’écran sont remarquablement similaires dans leurs fonctionnalités et dans leurs capacités, mais il y a des différences entre eux. Les raccourcis clavier d’un lecteur d’écran sont rarement les mêmes pour les autres lecteurs d’écran. Les voix des différents lecteurs d’écran ne sont pas identiques. Ils ont aussi des façons différentes de notifier aux utilisateurs les informations importantes, telles que les textes qui sont des liens, les éléments qui sont des images, etc.

Une question raisonnable à se poser à ce stade est de savoir si les développeurs devraient se soucier des différences entre les lecteurs d’écran. Si le contenu est accessible à une marque de lecteur d’écran, le sera-t-il à d’autres marques? Les développeurs devraient-ils personnaliser les contenus pour tenir compte des différentes capacités et des différentes spécifités des lecteurs d’écran ? Ces questions sont pertinentes mais difficiles à répondre. Les développeurs doivent déjà faire en sorte que leur contenu fonctionne bien avec plusieurs versions de navigateurs différents sur plusieurs plates-formes. C’est assez de travail pour ne pas avoir à se soucier des différentes versions des différents lecteurs d’écran sur les différentes plateformes.

La bonne nouvelle est que les techniques qui fonctionnent pour un lecteur d’écran fonctionnent presque toujours pour les autres lecteurs d’écran. Dans certains cas, l’un des lecteurs d’écran possède des capacités que les autres n’ont pas, ou gère certains types de contenu mieux que les autres lecteurs d’écran. Cependant, les développeurs ont presque toujours raison quand ils respectent les normes d’accessibilité au lieu de vouloir adapter le contenu aux spécificités des lecteurs d’écran. Mettre l’accent sur les différences entre les lecteurs d’écran peut conduire à la situation indésirable d’avoir des pages conçues justes pour JAWS ou juste pour Window Eyes, ce qui pourrait exclure les utilisateurs de lecteurs d’écran pour lesquels la page n’a pas été optimisée. Ce serait comme optimiser les pages pour un navigateur. Il y a encore quelques années, il était courant de lire sur les pages la mention « cette page est optimisée pour Internet Explorer (ou Netscape) ». Heureusement, cette pratique est devenue moins fréquente, et est généralement mal vue. La plupart des navigateurs Web et des lecteurs d’écran ont accordé plus d’attention aux normes au cours des dernières années, de sorte que l’expérience de l’utilisateur est tout à fait cohérente quelle que soit la technologie utilisée. Aucune des technologies n’est identique, ce qui peut conduire à des questions insolubles lors du développement mais elles sont suffisamment proches pour qu’il y ait peu d’exceptions aux « règles » de développement énoncées ci-avant.

Comment les lecteurs d’écrans lisent le contenu

Ce paragraphe présente comment les lecteurs d’écran lisent et prononcent le contenu. Il ne s’agit pas d’une liste exhaustive mais elle va aider les développeurs à comprendre un peu mieux le fonctionnement des lecteurs d’écran. La plupart des développeurs n’auront pas besoin de davantage d’informations que celles données dans ce document mais ceux qui sont intéressés devraient soit acheter des versions complètes des différents lecteurs d’écran, soit télécharger des versions d’essai.

• Les lecteurs d’écran s’arrêtent aux points, aux points-virgules, aux virgules, aux points d’interrogation et aux deux points.
• Les lecteurs d’écran s’arrêtent générallement à la fin des paragraphes.
• Les lecteurs d’écran essayent de prononcer les acronymes et les mots sans sens apparent s’ils ont suffisamment de voyelles/consonnes pour être prononçables ; sinon, ils épellent les lettres. Par exemple, l’acronyme NASA est prononcé comme un mot, alors que l’acronyme NSF est prononcé lettre à lettre comme « N.S.F. »; l’acronyme URL est prononcé « earl« , même si la plupart des personnes le prononcent plutôt lettre à lettre « U.R.L »; l’acronyme SQL n’est pas prononcé « sequel » par les lecteurs d’écran, même si certaines personnes le prononcent de cette manière; les lecteurs d’écran prononcent lettre à lettre « S.Q.L ».
• Les utilisateurs de lecteurs d’écran peuvent les arrêter quand ils ne comprennent pas un mot et peuvent lui faire répéter; ils peuvent même faire lire lettre à lettre les mots par le lecteur d’écran. Lors de la lecture des mots lettre par lettre, JAWS fait la distinction entre majuscules et minuscules en mettant l’accent sur les majuscules.
• Les lecteurs d’écran lisent les lettres au moment où elles sont tapées au clavier (ils disent « étoile » ou « astérisque » pour les lettres tapées dans les champs de mot de passe).
• Les lecteurs d’écran annoncent le titre de la page Web (balise <title> dans la balise <head>).
• Les lecteurs d’écrans liront le alt texte des images, si le alt texte est présent dans le code. JAWS prononce le mot « graphique » avant le contenu du alt texte. Si l’image est un lien, JAWS prononce l’expression « lien graphique » avant le contenu du alt texte.
• Les lecteurs d’écrans ignorent les images sans l’attribut alt dans le code et ne disent rien ou alors le nom du fichier image en fonction des préférences dans le paramétrage du lecteur d’écran.
• Si l’image sans attribut alt est un lien, les lecteurs d’écrans liront générallement la destination du lien (le contenu de l’attribut href dans le code HTML).
• Dans les premières versions de JAWS, il ne s’arrêtait pas après avoir lu un lien mais dans sa version 6, JAWS s’arrête, aidant ainsi les utilisateurs à faire la distinction entre le lien Web et le texte qui suit. Quand une image et du texte sont inclus dans le même lien, JAWS ne s’arrête pas entre les deux.
• Les lecteurs d’écrans lisent le alt texte des zones réactives d’une image map, mais pas nécessairement dans l’ordre visuel d’apparition dans la page. En terme de validité du code HTML, les zones réactives (balises <area>) n’ont pas à suivre immédiatement l’image dans le code HTML (balise <img>), mais les développeurs ne devraient pas les séparer en fait dans le code. Si l’image et ses zones réactives sont séparées dans le code, JAWS va lire le alt texte des zones réactives dans un ordre ne correspondant pas à l’affichage visuel dans le document.
• Les lecteurs d’écrans peuvent lire les titres de paragraphes. JAWS, par exemple, annonce « titre niveau 1″ avant de lire le contenu de la balise <h1> correspondant au titre de paragraphe de niveau 1.
• Les lecteurs d’écrans annoncent le nombre de liens dans une page dès que le navigateur Web a terminé de la charger.
• JAWS dit « lien dans la même page » quand la destination du lien est dans la même page que le lien lui-même.
• Les lecteurs d’écrans informent l’utilisateur du nombre de lignes et de colonnes dans un tableau quand le mode de navigation tableau est activé par l’utilisateur.
• Les utilisateurs peuvent naviguer dans toutes les directions de cellule en cellule (quand le mode de navigation tableau est activé). Si le tableau est correctement codé, le lecteur d’écran lira le titre de la colonne et/ou de la ligne auxquelles appartient la cellule quand l’utilisateur entre dans la cellule.
• Les lecteurs d’écran informent les utilisateurs quand ils accèdent à un formulaire. Les utilisateurs ont la possibilité d’activer le mode de navigation formulaire.
• Les versions récentes des lecteurs d’écrans peuvent automatiquement détecter les changements de langue (et changer alors la langue de la voix de synthèse) quand une page ou un mot dans une page est marqué dans une langue différente. Par exemple, si une phrase en espagnol apparaît dans une page en anglais, le lecteur d’écran peut la prononcer en espagnol si la phrase a été marquée ainsi : <span lang="es">Viva la patria</span>.
• La plupart des lecteurs d’écran prononcent les mots correctement dans presque tous les cas, mais parfois ils interprètent mal la différence entre les homographes (mots qui s’écrivent de la même façon mais qui ont des significations différentes et/ou des prononciations différentes). Par exemple (en anglais), le mot read peut être prononcé « reed » ou « red » en fonction du contexte : « I must read the newspaper » par rapport à « I have read the newspaper« . Une phrase telle que « I read the newspaper every day » est ambiguë pour tout le monde et aussi pour les lecteurs d’écrans. Cela peut signifier que l’auteur lit le journal chaque jour, ou que l’auteur avait l’habitude de lire le journal tous les jours. En fonction de ce que l’auteur a voulu dire, le mot read dans cette phrase peut être prononcée soit « reed » ou « red« . Le terme content est un autre exemple : « I feel content » (qui signifie heureux, avec l’emphase sur la seconde syllable [con-TENT]) par rapport à « Skip to main content » (qui signifie l’information principale, avec l’emphase sur la première syllable [CON-tent]).
• Les lecteurs d’écran lisent la plupart des ponctuations par défaut, telles les parenthèses, les tirets, les astérisques, etc. mais pas tous les lecteurs d’écrans lisent la même liste de ponctuations par défaut. Certains ne lisent pas les astérisques par défaut par exemple. Les points, les virgules et les deux points ne sont généralement pas lus de manière forte mais les lecteurs d’écran s’arrêtent généralement après les avoir lus. Les utilisateurs peuvent paramétrer leurs préférences de telle manière que les lecteurs d’écrans lisent chaque ponctuation et symbole.