Browser Games with Screen Reader Support

Screen reader support in browser games is rare and inconsistent. The format itself is friendly — HTML and ARIA were built to be accessible — but most game developers don’t expose game state to assistive technology. The browser games screen reader users can actually play tend to be text-based by design, or built by developers who treated accessibility as a feature rather than an afterthought. Here are the ones that genuinely work.

Lichess (chess server)

Lichess is the gold standard for accessible browser gaming. Its accessibility mode renders the board as a coordinate-based list (a1, b1, c1…) that screen readers parse cleanly. Moves are announced via text. Both casual and rated play work end-to-end with NVDA, JAWS, and VoiceOver. Free, no signup required for guest play.

Choice of Games catalog

Long-form interactive fiction published as web pages. The text is the game; choices are presented as labeled links. Screen reader navigation is identical to navigating any well-built website. Choice of Games has explicit accessibility commitments and tests their titles with screen readers.

Twine games on itch.io

Twine is the most-used browser-based interactive fiction engine. Its default output is clean HTML with text and hyperlinks — the most screen-reader-friendly format possible. Itch.io hosts tens of thousands of Twine games, many free. Quality varies wildly; the best are as good as published interactive fiction.

Adventuron text adventures

Adventuron is a browser-based retro text-adventure platform. Games are pure text with command-line input. Screen reader compatibility is excellent because the interface mimics a terminal. Several hundred completed games are playable for free.

Frotz-style Z-machine web players

Classic Infocom text adventures (Zork, Hitchhiker’s Guide, etc.) can be played in browsers via Z-machine interpreters like Parchment. These run the original 1980s game files in modern browsers, and because the games are pure text, screen reader compatibility is excellent.

A Dark Room

Doublespeak’s minimalist text-based survival game runs in browsers as plain HTML. The interface is buttons and text — no graphics. Screen readers handle it well. The game’s pacing (event ticks, text reveals) may need configuration in some screen readers to avoid speech interruption.

Lichess Puzzles

The puzzle mode on Lichess is screen-reader-compatible the same way the main chess is. Tactical puzzles announced via text, moves entered by coordinate. Daily puzzles, themed puzzle racks, rated puzzle climb — all accessible.

The candidly inaccessible category: mainstream arcade games

Most browser arcade games are not screen-reader friendly. The Chrome Dino game is a visual reflex game that doesn’t expose obstacle state to assistive technology. Slither.io, Krunker, Wordle (NYT), Bloons TD — none of these are designed for screen-reader play. Some have partial accessibility (keyboard-only controls, high-contrast modes) but the core game state is visual.

This isn’t a criticism of those games specifically — it’s the genre. Reflex-based arcade games are intrinsically visual. The accessible alternatives are turn-based games where state can be announced.

How to test screen reader compatibility yourself

Before committing to a game, a quick compatibility check:

• Load the game with your screen reader running. If the loading state isn’t announced, expect quiet gameplay.
• Tab through the page. Focus should land predictably on interactive elements. If focus disappears or jumps, controls likely aren’t keyboard-accessible.
• Look for ARIA live regions. Games that update state via aria-live=”polite” or aria-live=”assertive” will announce changes to your screen reader. Right-click the page and Inspect to see if these are present.
• Try the controls. Press the documented keys. If nothing’s announced and you’re not sure what happened, the game isn’t communicating state through assistive tech.

What the browser actually provides

The web platform has excellent accessibility primitives — semantic HTML, ARIA roles, focus management, the announce-on-change pattern. Games that use them work well. Games that render everything to a Canvas element without exposing state through ARIA effectively become black boxes to screen readers.

The W3C ARIA Authoring Practices Guide documents the patterns games should use. Most browser games don’t follow them; the ones that do are the games on this list.

Tools that help

Screen reader users testing browser games often use:

• NVDA — free Windows screen reader, the most common in accessibility testing.
• JAWS — commercial Windows screen reader; some games are tested specifically against it.
• VoiceOver — built into macOS and iOS; good for testing on the Mac side.
• Orca — open-source Linux screen reader.

Different screen readers handle the same game differently — even when a developer claims compatibility, “compatible” usually means tested against one or two specific readers.

Frequently asked questions

Which screen reader works best with browser games?

NVDA and JAWS are the most commonly tested on Windows; VoiceOver on Mac. Lichess tests against multiple readers. Choice of Games’ interactive fiction is generally compatible across readers because it relies on basic HTML semantics.

Can I play Wordle with a screen reader?

The official New York Times Wordle is partially accessible — letters can be heard, but the color-coded feedback (green, yellow, gray) doesn’t translate cleanly to speech. Some community variants address this with audio cues.

Why don’t more browser games support screen readers?

Most use HTML5 Canvas for rendering, which is a single opaque element to assistive technology. Exposing state through ARIA live regions requires explicit work most developers don’t do. The ones that do tend to come from the interactive fiction or chess communities, where accessibility is part of the culture.

Is the Chrome Dino game screen-reader friendly?

Not currently. The Chrome Dino game is a visual reflex game without audio cues for obstacles. The game state is rendered to a Canvas without exposed ARIA state. We’re aware of the limitation.

What’s the most polished screen-reader-compatible browser game?

Lichess for chess players. Choice of Games’ catalog for interactive fiction readers. Both are mainstream-quality products with explicit accessibility commitments rather than retrofit accessibility.

Where the genre needs to go

The browser is the most accessible game platform by default — the primitives are all there. The issue is that game developers don’t use them. The path forward is mundane: add ARIA live regions for state changes, use semantic HTML for menus, and test with at least one screen reader. The browser games that do this well already exist; we need more of them.