Accessibility in audio-first apps: what VoiceOver taught us about our own design

Both of our consumer apps are built around listening. That should make them good for people who do not see the screen well. It only does if the controls work without sight, and the first time we tested with VoiceOver, some of them did not.

Names for everything

A play button that VoiceOver reads as "button" is useless. Every control got a name that makes sense spoken aloud: "Play tonight's story", "Sleep timer, 20 minutes", "Keep this affirmation". Writing those names also exposed controls whose purpose we could not describe in a few words, which usually meant the control was wrong.

The night-time flow

A parent using VoiceOver at a child's bedside needs the same three controls everyone needs: play, pause, timer. We made sure they are reachable in order, with nothing in between, and that the timer announces its state. The remote-control principle we already had for the dark room turned out to be the accessible design too.

Dynamic Type

Larger text sizes broke layouts we were proud of: story titles wrapped badly, card decks overflowed. The fix was to let them. Layouts that adapt to the text size look less precious and work for far more people. A design that only works at one size works for fewer people than you think.

Captions and transcripts

The reverse case matters too. Every narrated story and scene has its text on screen, synchronised, so a person who cannot hear well, or a parent who wants to read along, is not excluded from an audio app.

What it taught us

Testing with VoiceOver found problems that affected everyone: unclear controls, screens with too many things on them, states the app did not announce. Accessibility work is not a separate checklist; it is a way of looking at the product that catches ordinary design mistakes early.