Text-to-speech eBook

Promesse tenue. 🙂

Après de très longues semaines de tests, plusieurs collectes de données, une vérification de ces collectes et un travail de synthèse plutôt conséquent, le récapitulatif text-to-speech eBook est enfin publié.

 

Récapitulatif Matériaux

 

Ce billet, pourtant, est un simple point d’étape. Nous sommes en réalité encore très loin de pouvoir proposer quelque chose d’exhaustif, il reste énormément de choses à tester. Cela inclut des plateformes entières, Windows en l’occurrence, mais aussi des outils, apps et spécifications techniques dédiées (EPUB3 + ARIA).

Rappelons que le text-to-speech eBook (ou synthèse vocale, la lecture étant effectuée par l’appareil) est à différencier de la fonctionnalité « Read Aloud », soit un morceau audio enregistré par un acteur et synchronisé avec le texte.

Et rappelons aussi que le Read Aloud ne peut se présenter systématiquement comme une alternative de meilleure qualité, donc une solution toute trouvée aux défauts de la synthèse vocale, puisque beaucoup d’utilisateurs y préfèrent tout simplement cette dernière — et ce n’est pas forcément négociable.

Je tiens à souligner que nous avons fait le choix d’ouvrir les matériaux de test, le récapitulatif et cet article de blog à tous, dans l’objectif de faire avancer les choses plus rapidement et d’obtenir les retours éclairés de spécialistes en accessibilité. C’est pour cette raison que l’intégralité des travaux effectués est placée dans le domaine public — cf. Elon Musk et les photos SpaceX, il n’y a absolument rien à perdre à un niveau personnel, il y a énormément à gagner à un niveau collectif.

Remarque

Le text-to-speech ne constitue qu’une infirme partie du concept d’accessibilité tel que défini par le W3C. Il ne peut en aucun cas représenter l’accessibilité du livre numérique, a fortiori celui du reflowable text, dans son ensemble.

Pensons en effet à la table des matières liée ou aux réglages utilisateurs permettant de modifier la composition en augmentant la taille de caractères, en modifiant le fond de la page ou en sélectionnant une autre police. Toutes ces choses permettent déjà de rendre les contenus d’un livre numérique accessible.

Reste que la synthèse vocale peut au moins donner une idée de comment le moteur de rendu comprend les contenus de notre livre. Et rien que pour ça, ça vaut le coup de le lancer : il nous permet ainsi et surtout de mieux les concevoir pour tous les cas de figure.

Méthodologie

Dès le départ, nous voulions fournir un « outil » pratique qui puisse être utilisé par tous ceux qui fabriquent des livres numériques, instantanément. Aussi, une grande partie de notre attention s’est portée sur les contenus à proprement parler, ce qui permettrait d’établir une liste d’observations à l’usage des éditeurs, correcteurs, concepteurs et développeurs.

Après tout, le plus gros des livres publiés sont des romans, soit essentiellement du texte, et nous souhaitions par conséquent ne pas nous en tenir à un seul « audit » technique. C’est la raison pour laquelle nous avons décidé de partir sur le format EPUB 2, en essayant d’y placer des choses (simples) susceptibles de poser souci aux lecteurs d’écran : abréviations, chiffres romains, listes, tableaux, caractères unicode, signes mathématiques, mots en langue étrangère, etc.

Toutes ces choses peuvent très facilement se trouver dans les livres numériques que nous fabriquons, il était donc important que nous les privilégions lors de cette première étape.

Bien naturellement, nous en avons également profité pour vérifier quelques bonnes pratiques théoriques (du web) dont les bienfaits n’avaient, à ma connaissance, jamais été encore confirmés en pratique pour le livre numérique, tout du moins publiquement : structure sémantique, texte alternatif pour les images, déclaration de la langue, etc.

Remarque

Mon expérience en tant qu’utilisateur occasionnel ne peut bien naturellement être comparée à celle d’un utilisateur régulier de lecteurs d’écran.

Je tiens tout de même à souligner que la « vie » fut bien compliquée une fois que VoiceOver ou Talkback étaient lancés sur les tablettes utilisées lors des différents tests, notamment quand je me suis mis à tester des fichiers EPUB fixed-layout contenant des éléments interactifs. J’y reviendrai à la fin de ce billet.

Louis croix vé bâton

Je ne vais pas mentir, certaines observations pourront se révéler décourageantes. Dire que tout n’est pas parfait tiendrait ici de l’euphémisme.

Par exemple, nous partons du principe que le lecteur d’écran gérera au mieux les images qui apportent du sens si celles-ci sont décrites à l’aide de l’attribut alt plus ou moins dédié. Dans les faits, ce n’est pas toujours le cas, soit parce qu’il y a un bug, soit parce que le lecteur d’écran ne s’en encombre pas.

Autrement dit, il faut éviter à tout prix le texte en image. Nous avons désormais des résultats tangibles pour démontrer que c’est l’une des pires pratiques pour le livre numérique. Par extension, cela implique également qu’il va nous falloir trouver très rapidement une solution pour que les descriptions des images qui apportent des informations supplémentaires soient lues à coup sûr.

Et malheureusement, tout n’est pas rose non plus en ce qui concerne le texte…

Si les siècles en chiffres romains sont globalement à l’abri, ce n’est pas le cas des noms de rois ou des numéros de chapitre. Ainsi, Kindle se fendra d’un « Louis Hicks Vé Hi » là où les autres lecteurs d’écran reconnaitront ce bon vieux « Louis Seize ». Quant aux numéros de chapitre, les lettres seront simplement prononcées par toutes les solutions.

Plus généralement, l’unicode n’est pas sans poser différents soucis en fonction des plateformes, les tableaux et listes demandent une attention particulière, le texte caché à l’aide de display:none; ou visibility:hidden ne le sera pas forcément pour tous, des passages dans certaines langues étrangères ne seront tout simplement pas lus, etc.

Au final, il y a beaucoup de micro-éditions à entreprendre dans le texte lors de la fabrication des fichiers si nous visons l’objectif de clarté.

Une modeste liste

Je ne me permettrai pas de présenter une liste de bonnes pratiques. Pour cela, nous aurions en effet besoin de la confirmation de spécialistes qui traitent de l’accessibilité au quotidien.

Ce que je peux néanmoins faire, c’est de lister quelques observations que nous devons à mon sens prendre en considération :

  • le nom des fichiers XHTML peut-être lu par le lecteur d’écran ;
  • la structure sémantique est utile puisque certains lecteurs annoncent la nature du contenu (rôle ARIA) en fonction de la balise HTML5 utilisée en EPUB3 ;
  • l’ordre des contenus dans le fichier XHTML doit absolument être l’ordre logique (de lecture) ;
  • les chiffres romains doivent être évités pour les numéros de partie et de chapitre, les lettres étant systématiquement lues en lieu et place du numéro ;
  • dans le doute, mieux vaut prendre soin d’écrire les choses en toutes lettres : « numéro » plutôt que « n° », « un quart » plutôt que « 1/4 » ou le caractère unicode correspondant, « un kilomètre » plutôt que « 1 km », etc. ;
  • les signes mathématiques doivent absolument être utilisés, pas le caractère qui leur ressemble le plus ;
  • tout ce qui ne doit pas être présent dans le fichier doit être effacé et pas uniquement caché, ce qui est caché pouvant être lu par beaucoup de lecteurs d’écran ;
  • si une image apporte une information supplémentaire, une légende reste le meilleur moyen de rendre cette information accessible, le texte alternatif n’étant pas forcément lu ;
  • pas de texte en image, plus jamais ;
  • pour assurer une lecture correcte des sigles, séparer les lettres avec des points ;
  • tableaux et listes gagnent à être annoncés par une phrase introductive, directement dans le texte ;
  • les tableaux sont systématiquement lus de gauche à droite, il faut le prendre en compte pour en rendre certains compréhensibles ;
  • s’il est possible de présenter les tableaux sous une autre forme, mieux vaut le faire ;
  • les puces et numéros de listes sont rarement lus ;
  • la déclaration xml:lang d’un passage en langue étrangère est utile puisque certains lecteurs d’écran pourront mieux les prononcer (meilleure compréhension) ;
  • l’attribut title n’a aucun impact audible ;
  • pour rendre le contenu accessible aux lecteurs d’écran lorsque le RMSDK Adobe est utilisé par l’app, il faut passer en EPUB3 puisque le SDK Readium, accessible, est alors utilisé ;
  • le nouveau mode intermédiaire « Parole » d’iOS prononce les caractères unicode dans la « langue » de la police utilisée pour leur rendu (russe, japonais, etc.).

Les tableaux détaillés disponibles sur Google Docs pourront vous en apprendre plus si vous voulez approfondir le sujet. Si je ne souhaite pas en ouvrir l’édition à n’importe quel visiteur histoire d’éviter les mauvaises surprises et de conserver un semblant d’organisation, n’hésitez quand même pas à demander l’accès en écriture si vous souhaitez y contribuer.

Un mot sur le fixed-layout

Si je n’ai pas encore pu créer de fichier test EPUB3 et, par extension, un fichier test fixed-layout (mise en pages fixe), cela ne m’a pas empêché d’en tester quelques-uns « pour voir ».

Je ne vais pas cacher que les résultats sont pour le moment assez dramatiques :

  • bugs en pagaille (livre qui ne s’ouvre pas parce que la couverture à l’italienne est trop petite en miniature, impossibilité de tourner les pages, barre de navigation extrêmement imprécise, etc.) ;
  • contenus interactifs trop souvent inaccessibles car mal conçus (je devine que JavaScript et « z-index » n’y sont pas pour rien dans l’affaire) ;
  • contenus incompréhensibles car placés dans un ordre qui n’est pas logique (titre de section entre deux paragraphes alors qu’il devrait être placé en tout début de DOM) ;
  • sélection ou fonctionnalité « Parole » (un niveau intermédiaire d’iOS avant VoiceOver) cassées à cause de balises « span » inutiles mais exportées automatiquement par certains logiciels ;
  • neutralisation « preventDefault() » sur l’intégralité de la page qui casse complètement la navigation Voice Over ;
  • orientation imposée par défaut sans que l’utilisateur ne le sache, Voice Over n’annonçant pas le changement (dans la mesure où cela est proposé par le revendeur, j’aurais tendance à considérer cela comme un oubli ou un bug dont il a la responsabilité).

Et tout cela sur des fichiers commercialisés à l’heure actuelle.

J’attends donc avec impatience de pouvoir tester des fichiers fixed-layout parfaitement réalisés, à l’aide de toutes les spécifications techniques EPUB3 à disposition, pour voir si ce sont les fichiers qui posent problème ou le support du format en lui-même.

Sachant que l’on demande une version accessible en reflowable text si le livre est en fixed-layout pour EDUPUB, je ne cache pas que j’envisage la seconde option plutôt que la première…

En conclusion

Je le rappelle, il nous reste énormément à faire.

Bien sûr, il faudrait compléter le tableau avec les résultats de lecteurs d’écran auxquels nous n’avons pas accès.

Dans l’idéal, il faudrait également compléter le contenu avec toutes les choses que nous aurions oubliées. Je pense notamment à « cf. » ou « c.-à-d. », aux titres de civilité comme « M. » ou « Dr » ou à des choses comme « 1er », « 2e », etc. Il faudrait également tester du contenu avec structure HTML dégradée (balise span coupant un mot par exemple).

Une étape cruciale consistera à passer le fichier en EPUB3 afin de pouvoir y intégrer tout ce qui peut en améliorer l’accessibilité, WAI-ARIA notamment.

Le sentiment qui prévaut aujourd’hui, hétérogénéité des résultats aidant, c’est qu’il est vraiment difficile de tirer des conclusions et d’ériger une liste de bonnes pratiques pour la synthèse vocale. La seule chose dont nous soyons sûrs, c’est que beaucoup de pratiques conseillées n’amènent pas forcément d’améliorations « audibles » pour le moment.

Bien évidemment, cela ne signifie pas que nous devons délaisser le sujet. Cela nous démontre juste qu’il nous reste encore pas mal de chemin à faire. Le travail ne manque pas, j’espère donc sincèrement que vous aurez envie de le faire avec nous ; toutes les bonnes volontés seront les bienvenues.

 

Récapitulatif Matériaux

Liens utiles

N’hésitez pas à compléter cette liste dans les commentaires.

 

Billet (et tous matériaux) publié(s) dans le domaine public — il paraît qu’en France, c’est techniquement compliqué de le faire donc, au pire, on pourra se réorienter vers une licence CC0.


2 commentaires Text-to-speech eBook

  1. David Chambost

    Waouh. Je vais essayer de creuser ça quand j’en aurai le temps, voir si j’ai des retours utiles à faire passer.

    tout ce qui ne doit pas être présent dans le fichier doit être effacé et pas uniquement caché, ce qui est caché pouvant être lu par beaucoup de lecteurs d’écran ;
    Question : est-ce que les commentaires dans le code XHTML sont aussi concernés  ?

    1. Jiminy Panoz

      Je n’ai pas essayé mais je ne pense pas… mais il faudrait quand même pour vérifier qu’il n’y ait pas de bug à ce niveau-là.

      En résumé, là, on est vraiment sur du

      <p style="display:none|visibility:hidden">contenu caché</p>

      Ce qui, par exemple, peut aussi être du résidu (fonctionnel) d’un CMS pour gérer certaines choses à la sortie.

      Du coup, les commentaires ça devrait pas mais… ça ne me surprendrait pas que certains lecteurs d’écran le lisent, en fait.

Les commentaires sont fermés.