Interactive Fiction Accessibility and What Breaks It
Interactive fiction accessibility starts ahead of every other kind of game, because prose needs no label. What breaks it is what apps add around the text.
Interactive fiction accessibility starts from a better position than almost any other kind of game, because a page of prose is the exact format assistive technology was built to read. A paragraph needs no label, no caption and no description. What breaks a text app is nearly always something added around the text: a picture carrying information, an icon with no name, a prompt that moves before it has been heard.
- Android’s guidance states that you do not need to provide a
contentDescriptionfor aTextelement, because accessibility services announce the text themselves.- Android 14 supports font scaling up to 200 percent, so a layout built around one text size fails at a setting readers can already choose.
- Android recommends a touch target of at least 48dp by 48dp for every interactive element.
- Ren’Py ships a self-voicing mode that reads text aloud through a speech synthesizer, plus a clipboard mode for readers using their own assistive technology.
- Every common failure in a text app is attached to something on the screen that is not prose.
Why does interactive fiction accessibility start ahead?
Because the content and the accessible version of the content are the same object. In a graphical game, a locked door, a health bar and a facial expression all have to be translated into words by someone who remembered to do it. In a text work the words are the game. Android’s own documentation makes the asymmetry plain: every interactive element needs a description that “describes the element’s purpose,” while a Text element needs none, since services like TalkBack read it out as written.
That single exemption is most of the advantage. It means a story app can be built so that the parts requiring deliberate accessibility work are a handful of controls rather than a whole world.
What breaks a text app for a screen reader?
Four things, in rough order of how often they appear. Each one is an addition to the page rather than a property of the writing, which is why a plainer reading surface tends to be the accessible one by accident.
| Addition | What a screen reader encounters | What fixes it |
|---|---|---|
| An icon-only control | “button,” with no indication of what it does | a content description naming the action |
| A picture carrying plot | silence, or a file name read letter by letter | alt text saying what the picture shows |
| A timed prompt | text that changes before it has been read | no timer, or one the reader sets |
| A custom input widget | an unlabeled field, or no focus stop at all | a standard field with a real label |
The pattern holds across formats. Community discussion of parser games keeps returning to the same complaint, and it is never the prose: it is interpreters and authoring tools that assistive technology cannot navigate, and puzzles whose solution lives in an image.
The illustration problem is a text problem
A picture in a story is only a problem when the story stops repeating itself. If a scene says the door is ajar and also shows it, nothing is lost by not seeing it. If the only statement that the door is ajar is a drawing, the scene has silently become unreadable for some of its readers. This is one argument among several for one illustration per story rather than one per scene: a single picture at a known point is easy to describe, and easy to make optional.
Does the prose itself need any work?
It needs to survive the reader’s settings, which is a layout question rather than a writing one. Android 14 supports font scaling up to 200 percent, and the platform advises specifying text sizes in sp units so the system can apply the reader’s preference, and setting lineHeight in sp as well, because text in sp with line height in dp “doesn’t scale and looks cramped.”
Three things tend to break at that setting: fixed-height containers that clip the last line, buttons whose labels truncate to a single word, and columns measured in characters rather than in available width. All three are visible in under a minute of testing, and all three are invisible if nobody turns the setting on.
Contrast is the other quiet one. Android asks for a ratio of at least 4.5:1 for text smaller than 18sp, and 3:1 for larger text. A story app with a dark theme and a tasteful gray-on-gray caption will miss that more often than it misses anything in the main body.
How do you test an interactive fiction app in ten minutes?
Turn on the two settings most readers with low vision already use, then try to finish one scene. The failures announce themselves.
- Switch on your screen reader and reach the end of a scene using only swipes. Every stop should say what it is.
- Set the system font size to its largest step. Look for clipped lines and truncated buttons.
- Turn off sound and see whether anything was only conveyed by audio.
- Find the illustration, if there is one, and check whether its description tells you anything the text did not.
- Try to leave the scene and come back. Reading interactive fiction on your phone happens in interrupted minutes, and a story you cannot resume by touch is a story you cannot resume.
What should a story app provide, and what should it leave alone?
Two things, pulling in opposite directions: a voice for readers whose platform gives them none, and a page with as little on it as possible for everyone else.
What does self-voicing get right?
It covers the case where the platform’s own reader cannot reach the text, and it is worth copying for one detail in particular. Ren’Py documents a self-voicing mode in which “a speech synthesizer is used to read out text and other interface elements,” reachable from an accessibility menu, with a separate clipboard mode that copies text instead of speaking it so that it “can be with screen readers or other assistive technologies that will present the clipboard contents to the user.”
That second mode is the respectful part. A built-in voice that cannot be turned off competes with the one the reader has already configured to their own speed and voice. The useful version of the feature offers both, and treats the reader’s existing setup as the default rather than the fallback.
Where a quiet interface helps by accident
Most of what makes a reading app workable with a screen reader is restraint that was adopted for other reasons. Fabledrift, an interactive fiction app for Android, puts no stats, bars, dice, inventory grids or quest logs on the page, shows the cost of a story once before it starts and never again while reading, and gives each story a single illustration rather than one per scene. None of that was done for accessibility. All of it shrinks the number of things on the page that would need a name.
The same goes for pace. Nothing in a turn-based story has to happen before the reader is ready, which is why reading interactive fiction slowly, one scene at a time, costs nothing. The genre’s oldest habits — text in the center, no clock, your own words as input — are the habits an accessibility audit would have asked for anyway.
A short checklist for the store page
Before installing a story app, three answers tell you most of what you need. Does the screenshot show text with no permanent overlay of numbers? Does the description mention images, and if so, are they decorative or load-bearing? Is anything timed? A reading app that answers plainly on all three will usually hold up under a screen reader, because it has fewer places left to fail.
Sources
Frequently asked questions
Is interactive fiction accessible for blind players?
Usually more so than other kinds of game, because the whole work is text and a screen reader announces text without any extra effort from the author. The exceptions are the parts that are not text: icons, pictures, custom controls and anything on a timer.
What makes a text-based game inaccessible?
Almost always an addition rather than the prose itself. An image that carries information the text does not repeat, an icon-only button with no name, a field labeled only by placeholder text, or a prompt that moves on before it has been read aloud.
Do interactive fiction apps need built-in text to speech?
Not if the reader's own screen reader can already reach the text. A built-in voice helps where the platform has none, which is why Ren'Py offers both a self-voicing mode and a clipboard mode that hands text to whatever assistive technology the reader already uses.
How large should text be in a reading app on Android?
Large enough to survive the reader's own setting. Android 14 supports font scaling up to 200 percent, and Android's guidance is to specify text sizes in sp units so the system can apply that preference.