For most Claude Code users, the terminal UI is a convenience — colored diffs, a live spinner, streaming text that scrolls past. For blind and low-vision developers using NVDA or JAWS, those same things have been a wall. Screen readers choke on ANSI color codes, mispronounce decorative glyphs, and lose their place entirely when streaming output rewrites the same lines dozens of times a second. Some developers reported having to restart their screen reader or terminal mid-session just to keep working.
As of the July 2026 release, Claude Code ships a dedicated screen reader mode that addresses this directly. Here's what it changes, how to turn it on, and what's still rough around the edges.
What Screen Reader Mode Actually Does
Screen reader mode is an opt-in flag that switches Claude Code's rendering from its normal animated terminal UI to plain, static text output — the format assistive technology can actually parse reliably. Instead of redrawing lines in place (the trick that makes streaming responses look smooth to sighted users but reads as chaos to a screen reader), output is appended linearly, top to bottom, the way a screen reader expects a terminal to behave.
Specific fixes bundled into the mode:
- Decorative glyphs are hidden. Box-drawing characters, spinners, and progress bar animations — visual noise with no informational content — are stripped from the accessible output stream instead of being announced character by character.
- Transcript symbols read as labels, not literals. Where the visual UI shows an icon or symbol to indicate a tool call or file edit, screen reader mode announces a short spoken label instead of trying to sound out the glyph.
- Nested tables read in order. Diff views and structured output that render as nested tables visually now have a linear reading order, so a screen reader announces rows and columns in a sequence that makes sense instead of jumping around the layout.
- No mid-stream redraws. Text streams in and stays — Claude Code doesn't overwrite the same terminal region repeatedly, which was the root cause of screen readers losing their place or re-announcing content.
How to Enable It
Three ways to turn it on, in order of how permanent you want it:
# One-off, this session only
claude --ax-screen-reader
# Environment variable, persists for your shell session
export CLAUDE_AX_SCREEN_READER=1
# Permanent, in settings.json
{
"axScreenReader": true
}The settings.json flag is the one worth using if you're a daily screen reader user — it applies to every Claude Code session without needing to remember a flag or environment variable, and it survives updates. Add it to your global ~/.claude/settings.json to apply everywhere, or to a project's .claude/settings.json to scope it to one repo.
Why This Took a GitHub Issue to Ship
This wasn't a planned feature — it came out of accessibility bug reports filed directly against the CLI, including requests for a dedicated screen-reader mode and a simpler --no-ansi flag to strip color codes outright. The pattern matters: terminal-based AI coding tools were built by and for sighted developers, and accessibility gaps like this don't get caught in normal QA because they only surface for users running assistive technology. If you hit an accessibility issue with any CLI tool, filing it as a GitHub issue with your specific screen reader (NVDA, JAWS, VoiceOver) and what broke is the fastest path to a fix — this is proof it works.
What's Still Rough
Screen reader mode fixes the CLI's own output, but it doesn't change what's happening underneath. A few things to know going in:
- It's opt-in, not automatic. Claude Code doesn't detect that you're running a screen reader and switch modes for you — you have to set the flag yourself. There's no auto-detection yet.
- Third-party terminal emulators vary. Screen reader mode controls what Claude Code sends to the terminal, not how your terminal emulator or screen reader interprets it. iTerm2 + VoiceOver, Windows Terminal + NVDA, and a bare Linux TTY + JAWS won't behave identically even with the same flag set.
- Diff-heavy workflows are still verbose. Large file diffs read linearly now instead of as a jumbled table, but a screen reader still has to announce every changed line one at a time — there's no summarization layer yet that says "12 lines changed in function X" instead of reading the full diff.
- Third-party plugins aren't guaranteed compliant. If you're using community MCP servers, hooks, or output styles, their custom output isn't automatically covered by screen reader mode's formatting rules — a plugin author has to opt into plain-text-friendly output the same way Claude Code core did.
Who This Matters For
Roughly 2.2 billion people globally have some form of vision impairment, and a meaningful share of professional developers are blind or low-vision. Command-line tools have historically been more accessible than GUI IDEs precisely because text streams to a screen reader more predictably than a visual layout — but AI coding agents broke that assumption the moment they introduced live-redrawing terminal UIs, spinners, and streaming animations. Screen reader mode is Claude Code walking that back: keeping the power of an agentic CLI tool while restoring the plain-text contract that assistive technology depends on.
If you're a team lead evaluating Claude Code for a developer who uses NVDA, JAWS, or VoiceOver, this closes the gap that would previously have been a hard blocker. It's not a finished accessibility story — the rough edges above are real — but it's the first version that's usable rather than actively hostile to screen reader workflows.
The Takeaway
Enable it with "axScreenReader": true in settings.json if you or anyone on your team relies on a screen reader. It strips the visual chrome that made Claude Code's CLI unreliable for assistive tech — decorative glyphs, mid-stream redraws, unordered nested tables — and replaces it with linear, predictable plain text. It came from a filed GitHub issue, not a roadmap item, which is worth remembering next time an AI tool doesn't work with your assistive technology: report it specifically, because that's what got this shipped.
---
Building accessible software isn't optional at Like One — it's the mission. Our consulting team audits AI tooling and products for real-world accessibility, not just automated WCAG scans. Learn the fundamentals at Like One Academy.