Forcer les lecteurs d’écran à prononcer du texte correctement

Ce billet est une adaptation pour la langue française de l’article de Jonathan Avila : ZIP, Z I P, or Z.I.P.? Forcing Correct Pronunciation in Screen Readers

Tout d’abord, nous remercions Jonathan Avila de nous avoir permis d’adapter son article.

L’article de Jonathan commence par une allusion à la synthèse vocale d’un outil de GPS qui a parfois du mal à « expliciter » une abréviation ou un acronyme ou qui ne sait pas prononcer un mot évident pour nous. Par exemple, St-Savinien pourra être prononcé S T Savinien au lieu de Saint-Savinien. BD Magenta sera prononcé Bande Dessinée magenta au lieu de Boulevard Magenta. Ce n’est pas un drame pour la compréhension du texte, l’accessibilité ou la navigation, mais cela peut être gênant.

Il existe des solutions, pour qu’un terme, un nom dont la prononciation est importante pour les messages de communication d’une entreprise ou de tout autre organisme, soit prononcé correctement par un lecteur d’écran.

Il n’est généralement pas recommandé d’écrire les mots phonétiquement pour qu’ils soient correctement prononcés par un lecteur d’écran. Il est tout à fait compréhensible et acceptable qu’un lecteur d’écran fasse des erreurs de prononciation de temps en temps. La façon dont le mot est prononcé est déterminée par un ensemble de paramètres :

  • Le logiciel de lecture d’écran (NVDA, Jaws, etc.) ;
  • le moteur de synthèse vocale utilisé avec le lecteur d’écran (éloquence, eSpeak etc.) ;
  • et le contexte (mot, phrase, document, application, navigateur (Firefox, Chrome etc.), puisque les lecteurs d’écran fonctionnent différemment avec différents agents utilisateurs.

Afin de déterminer si le problème est général ou isolé, il peut être utile de faire des tests avec différentes combinaisons de navigateurs/technologies d’assistance et de comparer avec ce que vous savez de vos utilisateurs (utilisation de pc, mac, leurs préférences de navigateur, etc.).

Attention : les changements effectués pour forcer la prononciation par une synthèse vocale peuvent causer des erreurs de lecture avec un afficheur braille couplé à un lecteur d’écran. Ainsi, l’insertion d’espaces entre chaque caractère ou l’écriture phonétique d’un mot qui permet de le prononcer correctement mais en dénature l’orthographe peut être gênant pour la personne qui lit le texte avec un terminal braille.

Prenons l’exemple du terme ViP. Tel qu’il est écrit ici, éloquence pour NVDA prononcera Vippé. Pour le forcer à dire chaque lettre séparément, on peut écrire les trois lettres en majuscules séparées par des espaces et ne pas les afficher à l’écran pour que cette façon d’écrire ne soit vue que par le lecteur d’écran. Si l’on écrit V I P, il se peut que la synthèse vocale prenne le V pour un 5 en chiffres romains, qu’il dise donc 6 P. Si l’on veut que la synthèse prononce VIP à l’anglaise, une solution pourrait être d’écrire phonétiquement Vi aille Pi, de toujours écrire ce texte en mode masqué, donc seulement lisible par le lecteur d’écran. La difficulté se posera à nouveau pour la personne qui lit ce texte avec un terminal braille et ne comprendra pas forcément la signification de Vi Aille PI. Cette incompréhension aura également lieu, si la personne lit en braille abrégé, dont le principe est de raccourcir les mots par des combinaisons de lettres, comme ac pour avec, ou bj pour bonjour.

Les options possibles pour obliger le lecteur d’écran à prononcer le texte correctement

Les solutions proposées ne sont pas forcément très élégantes et pas toujours bien supportées. Voici cependant quelques solutions qui pourraient aider les lecteurs d’écran à parler correctement lorsque c’est nécessaire.

Il faut garder à l’esprit que la plupart du temps, beaucoup d’organisations ne souhaitent pas qu’on modifie le texte affiché à l’écran. C’est pourquoi, il sera nécessaire de positionner le texte tel qu’on souhaite qu’il soit prononcé par le lecteur d’écran, en-dehors de l’écran via CSS, ou par l’intermédiaire d’un attribut aria-label ou via une autre technique telle qu’un title ou un texte alternatif sur le contrôle concerné.

Espacer les caractères

Imaginons que vous vouliez que le lecteur d’écran prononce ABS en séparant les lettres et non ABBE ou ABSSE. Vous pourriez ajouter des espaces à l’abréviation A B S, ou ajouter des lettres pour que l’acronyme soit prononcé correctement. Mais comme évoqué précédemment, une personne lisant avec un terminal braille verrait ces lettres.

CSS audio

Jonathan indique dans l’article que CSS3 Speech est, selon lui, le meilleur moyen de régler ce problème de prononciation, mais pour l’instant il n’est supporté que par VoiceOver sous IOS. Il explique qu’avec les CSS audio, on peut faire épeler à un lecteur d’écran les chiffres d’un numéro ou prononcer boulevard au lieu de BD mais ce n’est pas bien supporté pour l’instant. Ces options comprennent mais ne sont pas limitées à l’épellation d’un texte caractère par caractère, la prononciation des nombres chiffre par chiffre et la prononciation de toutes les ponctuations.

L’article propose un exemple de code CSS :

<style>
.address, .phone, .zip {speak: digits;}
code {speak: literal-punctuation;}
.spell-out {speak:spell-out;}
</style>

Il propose enfin de Voir comment fonctionnent les CSS audio à l’aide d’un périphérique sous IOS.

Propriété ARIA

Nous ne sommes pas tout à fait d’accord avec l’argumentation de l’article, qui considère que cette solution n’est pas élégante. L’utilisation d’ARIA nous paraît, au contraire, être une bonne solution. Il s’agit d’employer les mêmes méthodes, telles que l’utilisation d’espaces, la mise en majuscules ou l’épellation phonétique en utilisant les propriétés ARIA pour essayer d’obliger les lecteurs d’écrans à prononcer le texte d’une certaine façon. En général, la solution aria-label fonctionne uniquement sur des éléments interactifs ou sur du contenu référencé par des éléments interactifs tels que l’élément label ou la propriété aria-labelledby.

Exemple :

<label for="zip" aria-label="zip code">ZIP Code</label>
 <input type="text" id="zip" >

La meilleure solution

Lorsqu’on utilise des acronymes ou des abréviations, il est préférable d’insérer leur signification la première fois qu’ils apparaissent dans le texte. On peut utiliser la balise abbr accompagnée du title qui contient la signification de l’abréviation, mais il faut garder à l’esprit que par défaut, les abréviations ne sont pas développées par beaucoup de lecteurs d’écran. Dans les autres cas où la prononciation n’est pas nécessaire, ne rien faire de particulier et laisser l’utilisateur de lecteurs d’écran se servir des commandes de son logiciel pour vérifier la prononciation. Les lecteurs d’écran ont tous des commandes permettant d’épeler les mots lettre par lettre et de prononcer chaque lettre phonétiquement si besoin ; ces commandes sont bien connues, elles existent depuis longtemps et les utilisateurs devraient être familiers avec ces commandes.

Dans certaines situations, telles qu’un examen, où une prononciation particulière est absolument nécessaire pour que l’examen soit juste, utilisez les méthodes décrites précédemment et laissez de la flexibilité à l’utilisateur pour choisir le mode qu’ils préfèrent. Faites des tests avec différents lecteurs d’écran, synthèses vocales, navigateurs et plateformes pour vous assurer que chaque solution est compatible avec l’accessibilité.