Existe-t-il des recherches sur ce qui rend un document audible meilleur qu'un autre du point de vue de l'utilisateur?
L'un de mes projets pour 2018 consiste à délimiter la possibilité de reproduire une gamme d'œuvres imprimées/visibles dans une version audible. Certains d'entre eux sont en fait de nature technique, ce qui m'a amené à penser à l'expérience utilisateur des utilisateurs qui écoutent ce contenu. Les utilisateurs peuvent souffrir de déficiences visuelles, mais beaucoup peuvent simplement choisir d'écouter ce matériel plutôt que de le lire (par exemple, il est plus facile d'écouter en conduisant vers/depuis le travail, etc.).
Il y a beaucoup de recherches sur les méthodologies de mise en page et le flux d'éléments de conception (texte, diagrammes, etc.) tels que le diagramme de Gutenberg, le modèle Z, le modèle F, etc. Je suis également au courant d'autres questions telles que Mise en page - recherche faisant autorité sur le flux naturel de texte, de tableaux et d'images .
Cependant, tous ces éléments concernent la conception de contenu imprimé et/ou visuel. Cette question, par contre, concerne les documents audibles (généralement les livres audio).
Notez que cette question ne concerne pas les podcasts en soi, mais la représentation audible du contenu visible existant tel que les romans, les manuels, les documents de référence, etc.
Évidemment, il y a un peu à ce sujet, d'où pourquoi ma question demande des références à toute recherche (si elle existe) sur les meilleures pratiques pour créer des versions audio de contenu imprimé préexistant.
Les utilisateurs malvoyants utilisent généralement un lecteur d'écran. Si vous n'en avez jamais essayé, je vous suggère fortement de rechercher les bases de son utilisation (vous en avez déjà un dans votre poche - VoiceOver et TalkBack sont intégrés à iOS et Android, il vous suffit de l'activer!), Et regardez quelques vidéos YouTube qui montrent comment les utilisateurs de lecteurs d'écran parcourent les documents au quotidien. Ce billet de blog a également quelques bonnes analogies expliquant comment cela fonctionne.
Vous remarquerez rapidement que, tout comme les utilisateurs visuels, les utilisateurs de lecteurs d'écran (SR) ne lisent pas les manuels et les documents de référence comme un roman, Word by Word. Ils s'appuient fortement sur la structure comme les en-têtes, les paragraphes, les points de repère et les régions (encadrés, documents, graphiques ...) pour parcourir ce qui existe, donner un sens à ce qui existe et aller directement à la partie dont ils ont besoin. Lorsque les documents sont balisés sémantiquement, ces signifiants sont annoncés (par exemple "Niveau de titre 2", "Région complémentaire") et les lecteurs d'écran ont des raccourcis pour répertorier tous ceux disponibles et passer rapidement de l'un à l'autre.
Je ne sais pas si cela répond réellement à votre question, mais je pense que c'est un point de départ très pertinent pour comprendre comment les gens naviguent déjà dans l'audio. Parce qu'il s'agit de texte parlé, la "mise en page" sera plus ou moins linéaire, quoi qu'il en soit, donc votre meilleur point d'appel est de vous assurer de fournir une hiérarchie équivalente à ce qui existe visuellement.
Où aller ensuite dépend de ce que sont réellement votre public et vos documents: si vous voulez simplement les rendre accessibles aux personnes malvoyantes, assurez-vous simplement qu'ils sont disponibles dans un format accessible (HTML ou PDF) et sont sémantiquement balisés . Pour les documents qui ne sont pas des podcasts, ils préfèrent généralement utiliser leur propre lecteur d'écran plutôt qu'un fichier audio prédéfini, pour de nombreuses raisons (ils connaissent leurs raccourcis pour le parcourir, ils ont leurs propres paramètres et sont généralement habitués à un très débit vocal rapide, et les SR peuvent émettre vers des afficheurs braille s'ils ne veulent pas d'audio ou sont sourds-aveugles). Si vous souhaitez créer une version personnalisée de style podcast pour les personnes voyantes qui l'écoutent en déplacement, je n'ai pas d'articles spécifiques à vous renvoyer - mais je suggère quand même de penser autour des mêmes lignes. Utilisez la production, les effets sonores et les différentes voix pour refléter la structure des documents imprimés originaux.
J'apprends à créer de la documentation pour nos utilisateurs JAWS (lecteur d'écran) pour naviguer dans nos applications spécifiques à l'organisation.
Dans Word, les choses les plus importantes semblent être de s'assurer que le document utilise des styles (en particulier des en-têtes) au lieu de la mise en forme directe, car JAWS est "intelligent" et peut identifier ces en-têtes lorsque l'utilisateur appuie sur le raccourci "liste des en-têtes". En général, tout ce qui donne des indices sur la structure (CSS, XML) aide.
Une chose intéressante que j'ai trouvée est que PowerPoint est bizarre l'ordre de lecture visuel et l'ordre de lecture d'écran ne correspondent pas toujours - et cela peut être similaire à ce que vous trouvez dans InDesign ou n'importe quelle mise en page -programme concentré.
Freedom Scientific en parle ici dans la 3ème partie de la formation PPT .
Cependant, nous voulons également convertir un grand nombre de nos documents Word au format DAISY (Digital Talking Book), il est donc plus facile de vérifier la documentation ET le programme sur lequel ils sont censés fonctionner.
Voici quelques informations sur ce que fait XML pour Daisy: http://www.daisy.org/z3986/structure/SG-DAISY3/part1.html#auto_0001
Fondamentalement, c'est un XML qui se concentre sur la navigation dans le texte et avec synchronisation audio. OBI ( http://www.daisy.org/project/obi ) semble être l'outil d'édition audio qui s'intègre à DAISY. (Nous avons Dolphin au travail, mais je ne l'ai pas encore exploré.)
Les fabricants de JAWS utilisent parfois DAISY, vous pouvez donc obtenir un échantillon de ce à quoi ils ressemblent: Daisy Training Files for JAWS . Puisqu'ils travaillent avec et développent des outils pour les utilisateurs malvoyants et sans vision, je suppose que leur travail est au moins assez correct dans leurs choix de mise en page et de conception.
Je pense que la chose la plus importante à garder à l'esprit est la structure (invisible). Un utilisateur voyant doit utiliser très peu de mémoire à court terme pour naviguer - les yeux absorbent beaucoup d'informations très rapidement, donc si les utilisateurs voyants ne se souviennent pas si une icône était la 3e ou la 4e option - qui s'en soucie? Les utilisateurs axés sur l'audio ne peuvent pas voir l'écran (ou s'ils utilisent une loupe, ils ne peuvent pas tout voir), donc ils expérimentent le texte séquentiellement SAUF quand une bonne (mais invisible!) Conception permet l'utilisation de raccourcis de navigation.