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.

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.

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.

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.

• L’accessibilité des solutions de lecture les plus utilisées
• eBook et accessibilité
• Vue d’ensemble
• Appareils accessibles
• L’importance de Readium
• Guidelines a11y IDPF
• Site de Matt Garrish

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.