Screen Reader Preview

What does this tool do?

The Screen Reader Preview does three things: it simulates how a screen reader would read a block of text aloud, flags certain problematic patterns in the text -- such as ASCII art and tables, and provides practical recommendations for improvement. It's not a panacea. Rather, it's meant to help familiarize people with some of the most common issues and their potential solutions.

What is a screen reader?

A screen reader is a software program (assistive technology) that allows people with blindness or low vision to access content on their computer screen through a voice synthesizer or braille. The tool described here specifically aims to simulate the former -- the kind of screen reader that reads text aloud.

Why does this matter?

Things like ASCII art, maps, and decorative borders are very common in text-based games such as multi-user dungeons (MUDs), but they do not translate well into speech. A table that looks nice visually can sound like unhelpful gibberish when read aloud by a screen reader. Most people have never heard their content read aloud this way, so they don't realize how these things create barriers for players with visual disabilities.

How do I use it?

Paste any text into the input box -- room descriptions, help files, score screens, maps, whatever you want to test. Click Analyze & Read Aloud to hear the screen reader simulation and see flagged issues, or Analyze Only to just see the results without audio. You can also populate the input box with one of the built-in examples that are quite common among MU* games.

How accurate is the voice simulation?

It approximates how screen readers like NVDA and JAWS handle symbols, with a toggle for two punctuation levels: all (every symbol is spoken) and some (common sentence punctuation is skipped). These are simplified approximations -- real screen readers offer more granularity. The audio uses your browser's speech synthesis, not an actual screen reader engine. Treat this as a close preview, not a perfect replica.

What do the punctuation levels mean?

Screen readers let users choose how much punctuation is spoken aloud. Most offer several thresholds -- NVDA, for example, has four: none, some, most, and all. Each symbol is assigned a minimum threshold at which it gets spoken, so changing the level can dramatically change what you hear. This tool simplifies that into two options that cover the range most relevant to text-game content:

• All reads every symbol out loud. This is useful for understanding exactly what a screen reader user hears when the content is full of special characters -- which is the typical case for ASCII art, tables, and borders. It's the default here because it best demonstrates the problem.
• Some skips common sentence punctuation like commas, colons, semicolons, exclamation marks, question marks, and quotation marks, letting sentences flow more naturally. Periods and structural symbols (pipes, brackets, etc.) are still spoken. This is closer to how many users configure their screen reader for everyday reading.

These are simplified approximations, not exact replicas of any particular screen reader's behavior. Real screen readers offer more granularity and let users customize exactly which symbols are spoken at each level. These two options are enough to hear the difference between symbol-heavy content and flowing prose.

What issues can't it detect?

This tool uses pattern-matching heuristics, not AI. It may miss unconventional ASCII art, catch false positives on text that happens to be symbol-heavy, or not flag issues with unusual formatting. It also doesn't evaluate color codes, ANSI escape sequences, or MUD protocol-level features like GMCP or MXP. It analyzes plain text only.

There are also some other categories of text that can be difficult to understand when experienced audibly rather than visually. See "What about other text that is difficult to read?" below for some examples.

How do screen readers handle acronyms and all-caps words?

Screen readers use heuristics to decide whether an all-caps word should be spelled out letter by letter or pronounced as a word. If the word has enough vowels to seem pronounceable, the screen reader will try to say it as a word -- so NASA comes out as "nasa" and SAMI might become "sammy." If it looks unpronounceable, it gets spelled out: SQL becomes "S-Q-L." These heuristics vary between screen readers, so the same acronym may be handled differently by NVDA, JAWS, and VoiceOver.

Short abbreviations can also be interpreted as common English abbreviations rather than game-specific terms. For example, "DR" (damage reduction) might be read as "Doctor" or "Drive." Users can add custom dictionary entries to their screen reader to override specific words, but spelling out acronyms on first use (e.g. "Damage Reduction (DR)") helps both screen reader users and sighted newcomers understand what the abbreviation means.

What about other text that is difficult to read?

Beyond ASCII, there are other patterns of text that can be difficult to interpret when experienced audibly rather than visually. Although detection of these patterns is outside the current scope of this tool, it's important to be aware of them and how they can impact accessibility.

A few simplified examples:

• Pseudolanguage: An NPC speaks in garbled nonsense like "zrathk velm oqui shazza" when the PC doesn't know the language. A player with sight can skim or skip these passages. A screen reader will attempt to pronounce every word aloud every time.
• Backward text: A puzzle clue reads "RETAW EHT KEES" (seek the water). When spoken aloud, it might not offer the same experience as it would to a player solving the puzzle visually.
• Mixed languages: An NPC baker asks, "Voulez-vous du pain?" In the terminal, a screen reader set to English will apply English pronunciation rules, because it has no way to know that it should switch to French.

In practice, these kinds of patterns can range from mildly frustrating to extremely confusing for players. Implementations vary, so there is no one-size-fits-all way to address them. However, one helpful thing game admins can do is provide essential context. For example, adding something like "in French" or "in another language" would help screen reader users interpret the spoken text.

What is a screen reader mode?

Screen reader mode is a feature that a game can offer to make its output more accessible. Instead of requiring content creators to avoid all ASCII art, tables, borders, and maps, the game itself can programmatically strip out or replace those elements for players who opt in. This means the visual experience stays intact for sighted players, while screen reader users get clean, readable text.

For real-world examples of how this can work in practice, see this article.

Help! The read-aloud feature isn't working!

Speech synthesis depends on your browser and operating system. Make sure your browser is up to date for the best experience. Here's what to expect:

• Chrome / Edge: Best support. Voices load automatically. If speech cuts out on long text, this tool already works around that with chunked playback.
• Firefox: Works, but may use a different default voice. This tool pre-expands all symbols to spoken words before sending to the speech engine, so output should be consistent.
• Brave: Mixed results depending on operating system and environment. Some users report speech works normally, while others find Web Speech blocked or unreliable. If read-aloud fails in Brave, text analysis still works; try Chrome or Firefox for speech.
• DuckDuckGo: Privacy protections may block the Web Speech API entirely, causing voices to never load. Text analysis should still work, but for audio, try Safari (iOS/macOS), Chrome, or Firefox.
• Safari: Works on macOS and iOS. Uses the system voices from Settings > Accessibility > Spoken Content.

Troubleshooting on Linux: Unlike Windows and macOS, Linux browsers don't bundle their own text-to-speech engine. Instead, they rely on the system's speech-dispatcher service and a voice backend like espeak-ng. Most desktop distributions include these, but if speech isn't working, install them with sudo apt install speech-dispatcher espeak-ng (or your distro's equivalent) and restart your browser.

I found a bug or have a suggestion.

I'd love to hear from you. Please open an issue on GitHub with a description of the issue or your idea. If you can include the text that triggered the problem, that helps a lot. You can also drop by the Writing Games Discord server to share your feedback, if that's easier.

What fonts does this page use?

This page uses Atkinson Hyperlegible Next for all readable text and Atkinson Hyperlegible Mono for the input box and screen reader preview. Both were originally developed by the Braille Institute specifically to maximize character legibility for readers with low vision. Letterforms are designed so that similar characters (like l, 1, and I, or 0 and O) are easy to tell apart. These fonts are free, open-source, and a great choice for any accessibility-focused project.