text.games

Online text games that actually work with a screen reader.

A ranking is only honest if you state the axis.

"Best accessible text game" means nothing on its own. Here is exactly what we scored, how we weighted it, and — more importantly — what we have not verified.

The scoring axis

Composite score components and their weights.
Factor Weight What it measures
Accessibility depth 50% Is screen-reader support designed in — dedicated ports, visually-impaired modes, official soundpacks, in-game support channels — or merely incidental, in the sense that it is text so it kind of works?
Live population 30% Is anyone else online? A dead accessible game is a worse experience than a busy semi-accessible one.
Setup friction 20% Time from "I want to play" to actually playing. Web-playable beats a client download, which beats a client plus a 500 MB soundpack plus trigger config. Cost folds in here.

How community scores fit in

Signed-in readers can give any game a thumbs up or down and write a review. Those numbers appear on every entry — but they do not reorder the list. The ranking stays editorial, and the community score sits next to it so you can see when the two disagree.

That is a deliberate choice, and it cuts against us: if players consistently contradict a rating we gave, that is visible on the page rather than quietly averaged away. A vote-driven order would be more democratic and also more gameable; showing both costs us nothing but honesty.

Reviews may record which screen reader the player used. "Works fine" from a sighted keyboard player and from a JAWS user are different claims, and collapsing them would throw away the most useful thing a review here can tell you.

Accounts exist only to make spam harder. Your email is never displayed, shared, or sold; reviews are bylined with your username.

What we have and have not verified

Everything on this site is currently sourced from public documentation and blind-player community reports. We have not yet done our own hands-on screen-reader testing. That is the single biggest weakness of this ranking, and we would rather say so on every entry than let the star ratings imply more confidence than we have.

Each entry is tagged one of three ways:

  • Officially documented — the game or publisher documents its accessibility support.
  • Community-verified — blind players report it works, in forums or community wikis.
  • Accessibility unverified — plausible, but we found no accessibility-specific source.

Open work, in rough priority order:

  1. Hands-on screen-reader testing for every "unverified" entry.
  2. Real concurrent-player counts, rather than inference from vote-driven ranking sites.
  3. Coverage of Discord- and Telegram-hosted text games, a category this survey missed.
  4. Non-English coverage. QuentinC's Playroom runs in six languages; the rest of this list is anglophone-biased.

What the good ones do differently

  1. A dedicated port or mode beats a configuration guide. Alter Aeon's separate blind port treats accessibility as a server-side output mode rather than a burden pushed onto the client.
  2. ASCII maps are the number one failure. Cosmic Rage's advantage is largely the absence of them. Any map needs a linear-text equivalent.
  3. Sound is a parallel channel, not decoration. Audio progress bars restore what a visual status prompt gives sighted players, without stealing time in the speech queue.
  4. In-game support channels work. Help should live where the player is stuck — not on a website they would have to leave the game to read.
  5. Bots solve the empty-lobby problem. Accessibility without population is still a bad evening.
  6. Frames and heavy single-page apps break things. For web delivery: semantic HTML and ARIA live regions, not a canvas and not a frameset.

This site tries to follow its own advice. Every page is server-rendered HTML. The directory, reviews, voting, sign-in and the advertising all work with JavaScript disabled — they are ordinary form submissions, so they work in a text browser and on a braille display. Proper landmarks and headings, a visible focus indicator everywhere, no colour-only meaning, and full support for reduced-motion, high-contrast and dark-mode preferences.

The one exception: live chat

Each entry has a chat room, and the realtime version of it does need JavaScript. We are not going to pretend otherwise. It is the only page on the site that runs any, the code is first-party (compiled from our own Elixir), and the content security policy allows scripts from this domain only — no CDN, no third-party analytics, no inline script, no eval.

Every room also has a plain version that needs no JavaScript at all: read the transcript, post with a form, press a button to check for new messages. It is linked from the top of every room and it is not a stub — it is the same room.

What we deliberately did not do is fake realtime with an auto-refreshing page. A page that reloads itself throws a screen reader back to the top mid-sentence. That is a documented WCAG failure, and it would have made the "accessible" alternative worse than the JavaScript it was replacing.

In the realtime room, new messages are announced through a polite live region that waits for the current sentence to finish, focus never moves when a message arrives, the view never auto-scrolls, and announcements can be paused with one button — because a busy room that never stops talking is not accessible either.