One of my projects for 2018 involves scoping the possibility of reproducing a range of printed/visible work in an audible version. Some of these are actually technical in nature, so this got me to thinking about the user experience of users listening to this content. Users may suffer from visual impairment, but many may simply opt to listen to this material rather than read it (e.g. it's easier to listen to while driving to/from work, etc).

There is a lot of research into page layout methodologies and the flow of design elements (text, diagrams, etc) such as the Gutenberg Diagram, Z-Pattern, F-Pattern, and so on. I'm also aware of other questions such as Page layout - authoritative research into natural flow of text, tables and images.

However, all of these relate to the design of printed and/or visual content. This question, on the other hand, is about audible documents (typically audio books).

Note this question is not about podcasts per se, but about the audible representation of existing visible content such as novels, text books, reference materials, etc.

Obviously, there's quite a bit to this topic, hence why my question is asking for references to any research (if it exists) on best practice for creating audio versions of pre-existing printed content.

2 Answers 2


Users with vision impairments will typically use a screen reader. If you have never tried one, I would highly suggest looking up the basics of how to use one (you already have one in your pocket — VoiceOver and TalkBack are built into iOS and Android, you just need to enable it!), and watch a few YouTube videos that demonstrate how screen reader users navigate documents on a day-to-day basis. This blog post also has a few good analogies explaining how this works.

You'll quickly notice that much like visual users, users of screen readers (SR) do not read textbooks and reference materials like a novel, word by word. They rely heavily on structure like headings, paragraphs, landmarks and regions (boxes, documents, graphics...) to skim through what exists, make sense of what is there, and go directly to the bit they need. When documents are marked up semantically, these signifiers are announced (e.g. "Heading level 2", "Complementary region") and screen readers have shortcuts to list all those available, and quickly skip between them.

I don't know if this actually answers your question, but I think it is a very relevant starting point to understand how people already navigate through audio. Because it is spoken text, the "layout" is going to be more or less linear no matter what, so your best point of call is to ensure you provide an equivalent hierarchy to what exists visually.

Where you go next depends on what your audience and your documents really are: if you just want to make them accessible to people who are vision impaired, then just ensure they are available in an accessible format (HTML or PDF) and are semantically marked up. For documents that aren't podcasts, they will generally prefer using their own screen reader rather than a pre-made audio file, for many reasons (they know their shortcuts to navigate it, they have their own settings and are usually used to a very fast speech rate, and SRs can output to Braille displays if they do not want audio or are deafblind). If you'd like to make a custom, podcast-style version for sighted people just listening to it on the go, then I do not have specific papers to refer you to — but would still suggest thinking around the same lines. Use the production, sound effects and different voices to reflect the structure of the original printed documents.

  • I like the Australian woman voice in my Kindle reader. There is probably some guidance available on how to create an e-book so that the reader can work with it. Might apply to other sorts of content.
    – user67695
    Commented Mar 5, 2018 at 19:45

I'm learning to create documentation for our JAWS(screen-reader) users to navigate our organization-specific applications.

Within Word, the most important things appear to be making sure the document uses Styles (especially headings) instead of direct formatting, as JAWS is "smart" and can identify those headings when the user presses the "list headings" shortcut. In general, anything that gives clues to structure (CSS, XML) helps.

An interesting thing I found is that PowerPoint is weird visual reading order & screen-reading order don't always match -- and this may be similar to what you're finding in InDesign or any layout-focused program.

Freedom Scientific discusses it here in the 3rd part of the PPT training .

However, we also want to convert many of our Word documents to DAISY (Digital Talking Book) format, so it's easier to check documentation AND the program they're meant to be working on.

Here is some info on what the XML for Daisy specifically does: http://www.daisy.org/z3986/structure/SG-DAISY3/part1.html#auto_0001

Basically it's an XML that's focused on navigating within the text and with audio synchronization. OBI (http://www.daisy.org/project/obi) appears to be the audio-editing tool that integrates with DAISY. (We have Dolphin at work, but I haven't explored it yet.)

The makers of JAWS also use DAISY sometimes, so you can get a sample of what these are like: Daisy Training Files for JAWS. Since they work with and develop tools for low-vision and no-vision users, I assume that their work is at least pretty-ok in their layout and design choices.

I think the most important thing to bear in mind is (invisible) structure. A sighted user needs to use very little short-term memory to navigate - eyes take in a lot of information very quickly, so if sighted users don't remember if an icon was the 3rd or 4th option -- who cares? Audio-focused users can't see the screen (or if using a magnifier, they can't see all of it), so they experience the text sequentially EXCEPT for when good (yet invisible!) design allows navigation shortcuts to be used.

  • Thanks April, that's very useful. Thank you! :)
    – Monomeeth
    Commented Feb 15, 2019 at 0:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.