[FEATURE] Add a --screen-reader mode for better accessibility with NVDA and JAWS

This isn't platform:windows. Linux and Mac users will have similar problems for similar reasons.

This isn't platform:windows. Linux and Mac users will have similar problems for similar reasons.

Thanks Austin, github-actions added this flag, but I hope the developers reading this understand that it's a bigger problem and want to add this feature.

Hi. Another blind user here and I can confirm what @Ambro86 has said.
I can tell you that using the terminal app to run Claude Code seems to have mitigated some of the problems - though I just started trying and could be in my head too.
Would love for the proposed solutions to be implemented since ever since the forced migration to Windows 11 CC has been profoundly annoying to use.
Best regards,
Lundin.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Thanks for the reminder.
Yes, the issue is still present.
Claude Code is still hard to use with screen readers (NVDA, JAWS, Narrator) because of streaming output, spinners, and frequent line updates, which cause freezes, missed output, or terminal lockups.
This is not limited to Windows — the same behavior occurs on Linux and macOS for the same reasons related to TUI rendering and screen reader interaction.
Other blind users have confirmed this in the thread, and similar tools (e.g. Gemini CLI) have already addressed it with a dedicated --screen-reader / accessibility mode.
The issue is still relevant and affects basic usability for screen reader users.
I’m available to provide more details or help test if needed.

I mean sure I'll comment too, when my terminal locks up at least once a day in ways that are easily prevented I very much remember this issue. When I go into /config and have to hack around the men u using weird unicode that screen readers don't read using indentation indication and guessing to know what's selected, I remember this issue. These problems get discussed all the time amongst blind users as a whole. But all we can do is hope this gets triaged at some point and given enough attention, so yeah this specifically is silent about it.

I hope this gets noticed very soon, this is a major issue with claude code and screen readers and I am dealing with it every day.

Boris Cherny is on X soliciting feedback, I pinged there. Maybe some of you would want to as well. https://x.com/bcherny/status/2003916001851686951

You can get a slightly more stable experience by going into settings and disabling terminal progress bars (not what you think, it's control codes we can't see not the spinner) and by turning verbose output on (really, I have no clue whatsoever why turning verbose output on on my system seemed to help--maybe it's doing less crazy things with the terminal and just letting the text stream)? I still have issues--and these days those config menus themselves even have accessibility problems.

To work around the config menu accessibility turn indentationindication on and the less indented line is the selected one.

I'm aware of lots of people complaining about this stuff in my circles but the level of expertise needed to turn this into an actual GH issue for reporting is low so I don't think this is representative. I mean on the one hand number of blind programmers is super low but on the other hand if they understood enough about why it went wrong to report they probably would be.

I don’t like promoting myself, but until Anthropic fixes this issue, I added an accessible command prompt inside my editor (Novapad).
I tested it mainly with Codex, and it removes 100% of NVDA freezes and general system slowdowns. When NVDA freezes, it can crash the whole system.
If this can be useful to some blind developers, you can find it here:
https://github.com/Ambro86/Novapad/

Have just started dablling with Claude code, and am running into the same issue as stated. This is making the tool difficult to use by blind developers, so please show this issue some love! I looked into the novapad suggestion, but the program is crashing immediately after entering the terminal window. I'll try to dig into this when I get some more free time.

@techdog420 The terminal freeze problem is fixed in the new version of Novapad.
However, the accessible terminal cannot read the messages from Claude Code.
It works very well with Gemini CLI and with Codex CLI.
Probably Claude uses a different message system than the others.
If any developer can suggest a way to also capture the messages from Claude Code, it would be very appreciated.
By the way, I found some settings that, on my PC, stop Claude Code from freezing.
NVDA does not crash anymore and the window does not freeze.
I tried the method described by @ahicks92 , but in my case it was still freezing.
These are the settings I used.
Of course, change them for your own needs if you do not want some of them.
Relevant options I use:
Configure Claude Code preferences
Auto-compact: false
Thinking mode: false
Prompt suggestions: false
Verbose output: false
Terminal progress bar: false
Default permission mode: Accept edits
Theme: Light mode (ANSI colors only)
Notifications: Terminal Bell (\a)
Editor mode: normal
Model: Default (recommended)
Auto-connect to IDE (external terminal): true.

I would settle for a clarification as to whether or not using the agent SDK to write our own frontend to Claude Code, preferably by actually using Claude Code to do it, is against the terms or not. I don't want to get banned if I do it, but it is tempting.

if anyone starts a more organized campaign (say, an open letter), I am happy to sign it.

I have recently discovered that CC uses Ink: https://github.com/vadimdemedes/ink

(or according to Ink they do, anyway)

Ink's readme explains screen reader support, including for a subset of Aria. Just leaving this here in case it is useful whenever someone triages this.

I have created a Claude Code plugin that can announce permission prompts and last sentence from Claude in a conversation. It works with all major screen readers (JAWS, NVDA, Orca and Voiceover) on all major platforms (Windows, Linux, Mac), has fallback to a system speech synthesis engine.

Check it out https://github.com/raivisdejus/claude-code-plugins

My experience with assistive technologies is limited, feedback from real users would be appreciated.

A missing feature in Claude Code that would let to improve this plugin is a hook that fires when user changes permission mode (Approve edits -> Auto approve edits (shift+tab) -> Plan mode) With hook for this in Claude Code we could add an audio message for this to the users.

@raivisdejus Thank you very much for your plugin. I will surely try it.
I can say that now I have solved all the problems with Claude, using all the settings I mentioned. The problem is not that NVDA does not speak, but that it speaks too much. While typing, it often reads a series of numbers. I think this comes from the graphic interface used by the Claude CLI.
So for this reason your plugin could be useful. However, the problem is that NVDA will probably still read those numbers. We need to find a way to stop NVDA from reading them and use only your plugin.
I will try it and let you know. Thanks again for your project!

just commenting for increased visibility, also struggling with these issues

@Ambro86 Easiest way to prevent NVDA from speaking too much seems to put it to sleep with NVDA + shift + s when the terminal app is focused. In my tests this silenced all regular output from Windows PowerShell where Claude Code was running. Notifications from the plugin will work as they talk to NVDA directly and have fallbacks to regular speech API.

that's not sufficient for a variety of reasons, but I do appreciate the effort. Short of an alternate frontend however, I doubt that it will be possible to solve this via plugins. For example I do watch the chain of thought and diffs in realtime for steering purposes, permission prompts exist, settings menus, etc. It's not really solvable via plugins or hooks. For some context many/most of us outright use VSCode as our IDE--it's not just "make thing talk" that is involved here. But much of why I can use it at all is because some of these problems go away on a sufficiently powerful workstation, which I happen to have.

I am beginning to suspect that this issue will need (1) someone with an Anthropic contact or (2) some wider effort. I would like to think that if this gets seen something will be done, especially since that should be reasonably easy. I don't think that going from what it is now to fully screen reader friendly quickly would work but even a few simple things like using > instead of unicode in menus to mark the selected option would go a long way.

I was able to get a important fix out of Anthropic for claude.ai not that long ago. SO there is hope if someone looks in the right direction.

Just chiming in here as another frequent Claude Code user. I am routinely frustrated by the freeze issues which can sneak up without warning, requiring the restart of a terminal session, and sometimes just locking up NVDA completely. THis among with the other problems mentioned makes the experience far from optimal as a screen reader user

Hi, I am also using Claude Code with a screen reader and I can 100% confirm what the other users in this thread have said. I often have to restart NVDA and the terminal multiple times per session and in worst case even my whole pc. I would really appreciate a screen reader mode.

Just chiming in to also say I have similar issues, started using Claude Code today and these issues make me question the effort I'm putting in plus the £18 a month for the subscription, this needs to be sorted out, and the fact no one from Anthropic has come in and said anything in this thread is ridiculous.

I honestly switched to Claude Code because of all the hype, but I'll be going back to Codex as soon as my subscription ends. From web UI to Claude Code cli, Anthropic doesn't seem to care much about accessibility.

This is still an issue.

And Anthropic haven't bothered to get someone to respond to this, at this point I've just accepted it for what it is as I am actually getting some good use out of Claude Code, let's just say if it weren't for that I wouldn't have gotten as far as I have done in developing a new mobile Mastodon app.

I have also been facing these issues. I would also like to report that using the npm version of claude code removes much of the odd symbols. The installed version of claude code using the native installation has so many junk symbols that it is unusable for me.
I will try these settings to see if the freezing goes away. The freezing is really a productivity killer.
I use thinking mode and plan mode quite a lot. Do you know if that is really important?

Adding to this thread as a user of both NVDA on Windows and VoiceOver on macOS.

My main issue is with box-drawing characters (e.g., │, ─, ╭, ╰) used to render UI borders and tool call blocks. Screen readers announce these on every line, which constantly interrupts reading the actual output.

On Windows, the NVDA speech dictionary can suppress specific characters with some manual setup. On macOS, VoiceOver has no effective way to filter them out, so every response boundary and tool block gets read aloud.

A --screen-reader mode or --no-ansi flag that swaps box-drawing characters for plain ASCII — or removes decorative borders entirely — would make Claude Code significantly more efficient to use with a screen reader.

Following up on @ahicks92's point about having to guess which option is selected in menus — I found a workaround that helps with this.

Setting NO_COLOR=1 in your environment causes Claude Code to display a ❯ (Heavy Right-Pointing Angle Quotation Mark, U+276F) next to the selected option instead of relying on color alone. NVDA does not pronounce it, but it shows up on a braille display, which makes menus navigable without guessing.

To enable it permanently, add this to your ~/.bashrc:

export NO_COLOR=1

Relevant options I use: Configure Claude Code preferences Auto-compact: false Thinking mode: false Prompt suggestions: false Verbose output: false Terminal progress bar: false Default permission mode: Accept edits Theme: Light mode (ANSI colors only) Notifications: Terminal Bell (\a) Editor mode: normal Model: Default (recommended) Auto-connect to IDE (external terminal): true.

1. Note I think the "Theme: Light mode (ANSI colors only)" is the primary culprit for the slowdown.
2. There is always a greater sign when arrowing through items like /config. It's not nice, but if you down arrow or up arrow, you will be able to see the greater sign move ">". I am using the npm install of claude code.

I've been following this thread and built an open-source tool that addresses the output formatting side of these problems: claude-sonar.

I've been using Claude Code like it's a religion for the past year, and reading this thread honestly horrified me. The tool output is already spammy just visually reading it — I can't imagine what that experience is like through a screen reader. So I built this.

It uses Claude Code's hooks system to intercept tool output and reformat it into screen-reader-friendly summaries. Instead of raw JSON or walls of code, you get concise announcements like "Edited auth.ts, changed login function" or "npm test failed, 47 passed, 2 failed."

What it does:

• 14 tool formatters — tailored summaries for Bash, Edit, Read, Write, Grep, Glob, etc.
• Optional TTS — spoken announcements via say (macOS) or spd-say (Linux)
• Earcon sounds — short audio cues (chime for test pass, thud for test fail, etc.)
• Code summarization — when reading/editing files, announces function and class names instead of raw code
• Significance filtering — suppresses noisy routine events, highlights important ones
• Configurable verbosity — from compact (minimum output) to full detail

What it doesn't solve:

• The TUI rendering/NVDA freeze issues that @ahicks92, @Ambro86, @BlindGuyNW, and others have described. That's a deeper problem in how Claude Code renders to the terminal — hooks can't fix that.
• The box-drawing characters and menu navigation problems @rperez030 and @frastlin mentioned. Those need upstream changes in Claude Code itself.

This is complementary to @raivisdejus's plugin — their approach talks directly to screen reader APIs (JAWS, NVDA, Orca, VoiceOver), while claude-sonar focuses on reformatting the tool output itself into something that makes sense when spoken.

Install: npm install -g claude-sonar && claude-sonar setup

A note on what this is: I'm putting this out as a seed project for the community, not something I plan to actively maintain long-term. It's MIT-licensed, has 545 tests, full docs, and a CLAUDE.md so that Claude Code itself understands how to work on it — the intended workflow is to use AI-assisted development to contribute. My hope is that people who actually live with screen readers daily will fork this and shape it into what they need. I'll try to respond to bug reports, but this is meant to be yours.

There may be bugs — the scaffolding is solid but I'm not a screen reader user, so the output quality needs real-world feedback. There's a dedicated screen reader feedback template for reporting output that sounds wrong or confusing.

I've been following this thread and built an open-source tool that addresses the output formatting side of these problems: claude-sonar. I've been using Claude Code like it's a religion for the past year, and reading this thread honestly horrified me. The tool output is already spammy just _visually_ reading it — I can't imagine what that experience is like through a screen reader. So I built this. It uses Claude Code's hooks system to intercept tool output and reformat it into screen-reader-friendly summaries. Instead of raw JSON or walls of code, you get concise announcements like "Edited auth.ts, changed login function" or "npm test failed, 47 passed, 2 failed." What it does: 14 tool formatters — tailored summaries for Bash, Edit, Read, Write, Grep, Glob, etc. Optional TTS — spoken announcements via say (macOS) or spd-say (Linux) Earcon sounds — short audio cues (chime for test pass, thud for test fail, etc.) Code summarization — when reading/editing files, announces function and class names instead of raw code Significance filtering — suppresses noisy routine events, highlights important ones Configurable verbosity — from compact (minimum output) to full detail What it doesn't solve: The TUI rendering/NVDA freeze issues that @ahicks92, @Ambro86, @BlindGuyNW, and others have described. That's a deeper problem in how Claude Code renders to the terminal — hooks can't fix that. The box-drawing characters and menu navigation problems @rperez030 and @frastlin mentioned. Those need upstream changes in Claude Code itself. This is complementary to @raivisdejus's plugin — their approach talks directly to screen reader APIs (JAWS, NVDA, Orca, VoiceOver), while claude-sonar focuses on reformatting the tool output itself into something that makes sense when spoken. Install: npm install -g claude-sonar && claude-sonar setup A note on what this is: I'm putting this out as a seed project for the community, not something I plan to actively maintain long-term. It's MIT-licensed, has 545 tests, full docs, and a CLAUDE.md so that Claude Code itself understands how to work on it — the intended workflow is to use AI-assisted development to contribute. My hope is that people who actually live with screen readers daily will fork this and shape it into what they need. I'll try to respond to bug reports, but this is meant to be yours. There may be bugs — the scaffolding is solid but I'm not a screen reader user, so the output quality needs real-world feedback. There's a dedicated screen reader feedback template for reporting output that sounds wrong or confusing.

I'll definitely check this out, thank you. As for the freezing issues, they've completely disappeared since I've switched to windows terminal. I had uninstalled it a while back due to issues I no longer remember with it, but since reinstalling it and using it, the experience is as good as can be expected.

Hi @ahicks92

I was able to get a important fix out of Anthropic for claude.ai not that long ago. SO there is hope _if_ someone looks in the right direction.

if you still have that contact, it seems like they are trying to add aria-live support for the chat section in claude.ai, but they are not doing it right, and it is causing even more issues. Apparently they are doing atomic updates to an aria-live region with each new text update, which causes screen readers to constantly restart reading the answer, and I can see that potentially expanding to the rest of the Claude ecosystem. It is wonderful that they are trying to improve the accessibility of the web UI, but without the right understanding or the right support, it can easily go in the opposit direction.

By the way, I'd like to say that I completely agree with your original comment here. small changes can make a significant difference in this space.

Seconding the aria-live issue. I submitted feedback already through another channel but this is definitely worth more attention.

--
Zachary Kline
@.***

On Fri, Mar 6, 2026, at 4:33 AM, Roberto Perez wrote:

rperez030 left a comment (anthropics/claude-code#11002) <https://github.com/anthropics/claude-code/issues/11002#issuecomment-4011492724> Hi @ahicks92 <https://github.com/ahicks92> > I was able to get a important fix out of Anthropic for claude.ai not that long ago. SO there is hope if someone looks in the right direction. > if you still have that contact, it seems like they are trying to add aria-live support for the chat section in claude.ai, but they are not doing it right, and it is causing even more issues. Apparently they are doing atomic updates to an aria-live region with each new text update, which causes screen readers to constantly restart reading the answer, and I can see that potentially expanding to the rest of the Claude ecosystem. It is wonderful that they are trying to improve the accessibility of the web UI, but without the right understanding or the right support, it can easily go in the opposit direction. By the way, I'd like to say that I completely agree with your original comment here. small change can make a significant difference in this space. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/11002#issuecomment-4011492724>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANWY45MCIQ7BFKDYEJMRA34PLAR7AVCNFSM6AAAAACLEKF6NCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMJRGQ4TENZSGQ>. You are receiving this because you were mentioned.Message ID: @.***>

Blind developer here — I have tried everything. Nothing works.

I am a blind developer using VoiceOver on macOS. I use Claude Code daily for real work. The box drawing characters, braille spinners, emoji, and decorative Unicode make VoiceOver read garbage constantly. Here is everything I have tried over several hours to work around this:

What I tried and why it failed

1. VoiceOver Pronunciations (legacy plist)
Added 67+ character substitutions to ~/Library/Preferences/com.apple.VoiceOver4/Default/Pronunciations.plist. VoiceOver ignored them all in Terminal. Single-character substitutions do not match against terminal screen buffer reads.

2. VoiceOver Pronunciations (Group Container plist)
Added 773 entries to the active plist at ~/Library/Group Containers/group.com.apple.VoiceOver/Library/Preferences/com.apple.VoiceOver4/default.plist. Still does not work. VoiceOver reads terminal screen buffer content differently from regular text — pronunciation substitutions do not apply.

3. VoiceOver Punctuation Level (VO+P)
Setting punctuation to "None" silences the box drawing but also silences all code-necessary punctuation (brackets, semicolons, parentheses). Not usable for a developer.

4. INK_SCREEN_READER=true environment variable
Ink supports this variable and has a useIsScreenReaderEnabled hook, but Claude Code does not use it to change its rendering. The box drawing characters are still drawn.

5. PTY proxy filter (claude-clean)
Built a Python PTY proxy that intercepts Claude Code output and strips decorative characters before they reach the terminal. Failed because Ink redraws the entire screen on every keystroke. Stripping ANSI codes either merges words together ("ClaudeCodev2.1.76") or leaves floods of blank lines. Each typed character appears on its own line. Fundamentally incompatible with Ink's full-screen TUI rendering model.

6. Pyte terminal emulator filter (claude-reader)
Built a second PTY proxy using pyte (a Python terminal emulator library) to properly parse escape sequences and rebuild a clean screen buffer. Same underlying PTY problem — Ink's constant full-screen redraws cannot be filtered at the byte level.

7. claude-sonar hooks plugin
Installed claude-sonar, a community hooks plugin for screen reader users. It only formats tool output (Read, Edit, Bash results). It does not touch the Ink UI frame itself. Also caused Stop hook JSON validation errors because it returned the wrong schema for Stop events.

8. claude -p wrapper (claude-accessible)
Built a Python wrapper around claude -p --output-format stream-json. This produced clean text output with no decorative characters. However, it loses critical interactive features: plan mode does not work (AskUserQuestion gets denied), permission prompts cannot be answered, and it is fundamentally single-shot per turn rather than truly interactive.

9. TDSR (terminal screen reader replacement)
Tried TDSR as an alternative to VoiceOver for terminal use. It reads output strangely and is not a good fit for Claude Code's Ink-based UI.

10. NO_COLOR=1 and TERM=dumb
Neither changes Claude Code's rendering of decorative characters.

What actually works

Nothing. There is no way for a blind developer to use the full interactive Claude Code terminal experience without VoiceOver reading decorative UI garbage.

The closest workaround is using Claude Code in VS Code, which has its own accessibility layer. But that means giving up the terminal workflow entirely.

What is needed

Gemini CLI already has a --screen-reader flag. Claude Code uses the same Ink framework and Ink already supports useIsScreenReaderEnabled. The infrastructure is there. Claude Code just needs to:

1. Check INK_SCREEN_READER=true or a --screen-reader flag
2. Replace box drawing borders with plain text or nothing
3. Replace braille spinners with text like "working..."
4. Strip emoji from status indicators
5. Use plain text separators instead of ───────────

This is not a nice-to-have. This is a barrier that prevents blind developers from using your product.

Another thing that needs addressed is a way in which to tell which autocomplete suggestion is focused, rather than receiving an entire list of them and being unsure which will be selected when pressing tab.

The new remote control feature opens interesting possibilities. I'm trying it out now. It only works on macOS at the moment. Essentially, you type "/remote-control", which creates a tunnel that allows us to control the active session either from claude.ai or the mobile app. They are not great either, but if you combine a few hooks to auto-speak permission prompts with instructions in claude.md to add a heading to the beginning of each response, it makes interacting with the session from claude.ai a much more pleasant experience. Right now, it seems like we have to focus the terminal from time to time because if it remains in the background for too long, the session gets disconnected. Unfortunately, it doesn't seem like we can build our own client. I'm also considering building a Web UI for claude code using hooks. I got the inspiration from https://github.com/johnmatthewtennant/mcp-voice-hooks.

Has someone in this thread explored the idea of submitting a PR to claude code? Would Anthropic accept that?

Blind user here, +1 we need better support from claude code for screenreaders. If you ever tried to use claude code on linuxwith Orca, well it is a pain! And with NVDA on windows, you have still issues. Please Anthropic look into this!

Note that the npm version of Claude Code seems to have less junk characters than the native installer.
Also note that OpenAI recently started contracting with a blind person to improve their interface, so Anthropic is very behind and will probably lose me as a customer soon.

Just introduced my wife to Claude, and because of her vision impairment, and her using JAWS, it is actually impossible to use it. Trying to "Tab" our way to the response in a chat session, it is actually impossible to get JAWS to focus, and thereby read any response. Extremely disappointing.

This sounds like you're introducing her to Claude Desktop rather than Claude Code CLI. I haven't used the desktop client for a while, but last I tried, if she were to Press the PC Cursor key in JAWS to drop out of forms mode, she should be able to arrow up and read the responses in the virtual buffer. It's a little clumsy, but I did get it to work.

@ceeol
Claude web also has headings etc. on claude.ai now, and works fine at least with NVDA.

If you are yourself sighted, you may not be aware, but mostly people do not use these kinds of apps by tabbing. That's true even of the most accessible ones as well. Being able to get to the message output with tab is just not a thing most of the time. Tab is only going to land her on buttons, edit boxes, and other normally focusable elements. I don't want to take this too far OT, but if you and her are only familiar with tab, you guys might want to look for training.

@glenrgordon
There is a Claude code desktop app and a lot of blind people use it. I can't provide details because I use the terminal one though.

Another blind NVDA user here. Sharing a setting that helped a lot, in case it's useful to others while a proper --screen-reader mode is pending.

Setting "prefersReducedMotion": true in ~/.claude/settings.json cut my screen-reader noise by well over 90% — to the point it's nearly silent. The biggest source of NVDA chatter for me was the live token counter on the spinner line (the "… · N tokens · esc to interrupt" line): it re-renders constantly, so NVDA kept re-reading the incrementing number nonstop. prefersReducedMotion freezes that animated re-render and the number stops being announced over and over — while keeping the useful static lines like "thought for Xs".

Restart Claude Code (or claude --resume) after setting it.

It's not a complete fix: the persistent token counter in the bottom status line still gets read occasionally (open requests to hide that: #21867, #22354), and it's obviously no substitute for the dedicated accessibility mode requested here. But as a quick mitigation it took my experience from noisy to almost silent, so worth sharing.

@ceeol I am also totally blind, using Jaws with Chrome. The CLI has proven extremely challenging, but the web interface is quite usable. In virtual cursor (non-application, non-forms) mode, you can navigate by headings, which Claude uses effectively to mark start/end of your prompt v. Claude's response. One thing to watch for is that the virtual buffer becomes full very quickly in these chats, and Jaws will become sluggish, and eventually stop responding at all. I monitor the length of the chat and the screen reader's responsiveness, and have Claude write me a prompt to kick off a new chat to continue from where I left off. I'm definitely going to try @kaeltosh 's suggestion, and there's also this claude-sr command, https://github.com/JacquelineDMcGraw/claude-a11y, which wraps claude with screen-reader-friendly switches.

Btw, houdy @glenrgordon - it's been some time! Haven't things changed????:)

This thread is exactly why I want to help. I use Claude Code daily and
want to make CLI coding agents genuinely usable with screen readers —
not as a one-off, but maintained.

I've been looking at the existing efforts here: claude-sonar
(github.com/vylasaven/claude-sonar, ~500 tests, on npm but no longer actively maintained and claude-a11y / claude-sr (github.com/JacquelineDMcGraw/
claude-a11y), plus the prefersReducedMotion tip above. There's real work
already — there's already installable work here — what seems missing is sustained maintenance and coverage of the other terminal agents (Aider, Codex CLI)

Rather than add yet another tool, I'd like to help push one of these to
"actually installable and maintained," and ideally extend the approach to
Codex CLI / Gemini CLI / Aider. Before I commit time in the wrong
direction, I'd value input from people who actually use screen readers:

1. What's the single most painful part right now — is it the streaming/

spinner noise, diffs, status lines, or something else?

1. Of the existing tools, does any come closest to what you'd actually

use day to day?

1. Would anyone be open to being an early tester / co-maintainer? I want

to build this with screen-reader users, not for them.

Thanks — happy to put the work wherever is most useful.

I’ve not tried Claude Sonar because of what it’s documented as doing: filtering command output. Unless I’m misunderstanding things, Claude will also see this filtered output. Great for screen reader users, not so great for Claudetaking action based on the output, especially if what gets summarized away might actually be relevant.

I’d be happy if someone can disabuse me of my understanding.

--Glen

From: StigJoe @.*>
Sent: Thursday, June 11, 2026 11:14 AM
To: anthropics/claude-code @.*>
Cc: glenrgordon @.>; Mention @.>
Subject: Re: [anthropics/claude-code] [FEATURE] Add a --screen-reader mode for better accessibility with NVDA and JAWS (Issue #11002)

<https://avatars.githubusercontent.com/u/264944309?s=20&v=4> StigJoe left a comment (anthropics/claude-code#11002) <https://github.com/anthropics/claude-code/issues/11002#issuecomment-4682597388>

I'm a developer who uses Claude Code daily and I want to help make CLI
coding agents usable with screen readers. I came across claude-sonar
(github.com/vylasaven/claude-sonar) — a hooks-based plugin that reformats
tool output into screen-reader-friendly summaries with optional TTS. It's
quite complete (~500 tests) but unpublished and no longer actively
maintained.

I'm considering picking it up: hardening it, publishing it to npm, and
extending it beyond Claude Code (Codex CLI, Gemini CLI, Aider) plus the
harder unsolved parts like accessible diffs and agent-status cues.

Before I build in the wrong direction, I'd really value input from people
who actually use screen readers:

1. What's the single most painful part of using Claude Code (or other AI

CLI tools) with a screen reader right now?

1. Would a maintained version of something like claude-sonar be useful to

you?

1. Would anyone be open to being an early tester / co-maintainer? I want

to build this with screen-reader users, not for them.

Thanks — happy to go wherever is most useful.

—
Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/11002?email_source=notifications&email_token=AEMY6EIWO722VRGXKHHYIUT47LLFLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRYGI2TSNZTHA4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4682597388> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEMY6EK5TJ4IILLY4KQQR5L47LLFLAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TGNJYG44TGMJZGEY2C5QC> .
You are receiving this because you were mentioned. <https://github.com/notifications/beacon/AEMY6EOYX3WUONW4E2DHXAT47LLFLBFCNFSM6AAAAACLEKF6NCWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTYAAAAACFY2YQGKM4TFMFZW63VHNVSW45DJN5XA.gif> Message ID: @. @.> >

For me the biggest problem with CLI for Claude or pretty much any of the terminal versions of these apps is the ways they are writing to the terminal window. Traditionally, screen readers could echo back what was sent to the terminal just once and then you could use screen reading commands to review that information in detail. The second part kind of works but the real problem now is that text is being echoed back multiple times and not just in response to a command being entered. In fact in my Claude terminal windows, if I type a single character, the full window content starts to be reread. Type a second character and you start over with everything being repeated.

I recognize this is a very high level explanation and not enough detial to really dig into solving the problem. If others watching this thread want to chime in, please do with more details.

On Thursday, June 11, 2026 11:14 AM, "StigJoe" @.***> wrote:

StigJoe left a comment (anthropics/claude-code#11002)

I'm a developer who uses Claude Code daily and I want to help make CLI

coding agents usable with screen readers. I came across claude-sonar

(github.com/vylasaven/claude-sonar) — a hooks-based plugin that reformats

tool output into screen-reader-friendly summaries with optional TTS. It's

quite complete (~500 tests) but unpublished and no longer actively

maintained.

I'm considering picking it up: hardening it, publishing it to npm, and

extending it beyond Claude Code (Codex CLI, Gemini CLI, Aider) plus the

harder unsolved parts like accessible diffs and agent-status cues.

Before I build in the wrong direction, I'd really value input from people

who actually use screen readers:

1. What's the single most painful part of using Claude Code (or other AI

CLI tools) with a screen reader right now?

2. Would a maintained version of something like claude-sonar be useful to

you?

3. Would anyone be open to being an early tester / co-maintainer? I want

to build this with screen-reader users, not for them.

Thanks — happy to go wherever is most useful.

--

Reply to this email directly or view it on GitHub:

https://github.com/anthropics/claude-code/issues/11002#issuecomment-4682597388

You are receiving this because you are subscribed to this thread.

Message ID: @.***>

@kellylford That behavior, typing individual characters and getting the entire window read, may be Claude CLI-specific, but not all problems reading in TUIs specific to claude CLI. That, as far as I know, is a problem with Jaws working with the newer console/terminal window in Windows 11. I face a lot of similar issues using WSL terminals. Upon updating to Windows 11, the output in the console is not nearly as effectively read as in Windows 10. I stay on claude web until I'm ready to code for this reason.

That is my understanding as well, and personally I don’t think I would find a tool that produces summarized outputs helpful.

The biggest issue using the CLI for me is the vast amounts of decorative characters that Claude code produces. They are easy to filter out using Windows screen readers, but much more difficult to deal with on macOS with Voiceover. I mainly use CC either via the desktop app or via a remote session from claude.ai<http://claude.ai>. That combined with hooks, claude.md rules to produce structured output, and a good set of personal skills have proven to be very effective. I wish Claude code had a flag to suppress those ornamental characters in the CLI though.

On Jun 11, 2026, at 1:54 PM, glenrgordon @.***> wrote:

[https://avatars.githubusercontent.com/u/18452241?s=20&v=4]glenrgordon left a comment (anthropics/claude-code#11002)<https://github.com/anthropics/claude-code/issues/11002#issuecomment-4683425467>
I’ve not tried Claude Sonar because of what it’s documented as doing: filtering command output. Unless I’m misunderstanding things, Claude will also see this filtered output. Great for screen reader users, not so great for Claudetaking action based on the output, especially if what gets summarized away might actually be relevant.

I’d be happy if someone can disabuse me of my understanding.

--Glen

From: StigJoe @.*>
Sent: Thursday, June 11, 2026 11:14 AM
To: anthropics/claude-code @.*>
Cc: glenrgordon @.>; Mention @.>
Subject: Re: [anthropics/claude-code] [FEATURE] Add a --screen-reader mode for better accessibility with NVDA and JAWS (Issue #11002)

<https://avatars.githubusercontent.com/u/264944309?s=20&v=4> StigJoe left a comment (anthropics/claude-code#11002) <https://github.com/anthropics/claude-code/issues/11002#issuecomment-4682597388>

I'm a developer who uses Claude Code daily and I want to help make CLI
coding agents usable with screen readers. I came across claude-sonar
(github.com/vylasaven/claude-sonar) — a hooks-based plugin that reformats
tool output into screen-reader-friendly summaries with optional TTS. It's
quite complete (~500 tests) but unpublished and no longer actively
maintained.

I'm considering picking it up: hardening it, publishing it to npm, and
extending it beyond Claude Code (Codex CLI, Gemini CLI, Aider) plus the
harder unsolved parts like accessible diffs and agent-status cues.

Before I build in the wrong direction, I'd really value input from people
who actually use screen readers:

1. What's the single most painful part of using Claude Code (or other AI

CLI tools) with a screen reader right now?

1. Would a maintained version of something like claude-sonar be useful to

you?

1. Would anyone be open to being an early tester / co-maintainer? I want

to build this with screen-reader users, not for them.

Thanks — happy to go wherever is most useful.

—
Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/11002?email_source=notifications&email_token=AEMY6EIWO722VRGXKHHYIUT47LLFLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRYGI2TSNZTHA4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4682597388> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEMY6EK5TJ4IILLY4KQQR5L47LLFLAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TGNJYG44TGMJZGEY2C5QC> .
You are receiving this because you were mentioned. <https://github.com/notifications/beacon/AEMY6EOYX3WUONW4E2DHXAT47LLFLBFCNFSM6AAAAACLEKF6NCWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTYAAAAACFY2YQGKM4TFMFZW63VHNVSW45DJN5XA.gif> Message ID: @. @.> >

—
Reply to this email directly, view it on GitHub<https://github.com/anthropics/claude-code/issues/11002?email_source=notifications&email_token=AJH5KGRQP5MCUIR7YYYUZ7347LW37A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRYGM2DENJUGY32M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4683425467>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJH5KGVMOMOSMDIVAXSHPO347LW37AVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TGNJYG44TGMJZGEY2C5QC>.
You are receiving this because you were mentioned.Message ID: @.***>

Hello, I'm a developer using cloud.I also use jaws as my Windows screen reader and voiceover on my Mac.I used Claude on a daily basis, the terminal interface is problematic as you described it, it seems that the output is not properly red and also Choying a selection is not readable.But I found two workaround.The first is using the VS code extension, you renders the output terminal as an HTML and therefore overcoming all the noises and converting options to reel HTML selection.And the other is using the remote control command on cloud in which I can take to a browser could be on the same device and then I get a web interface for my CLI session.I think what we really need is a good terminal with accessibility features built-in in this way we can use either Claude or Open AI terminal. This would be a real benefit for the community.Shmuel NaamanOn 12 Jun 2026, at 0:30, Roberto Perez @.***> wrote:rperez030 left a comment (anthropics/claude-code#11002)
That is my understanding as well, and personally I don’t think I would find a tool that produces summarized outputs helpful.

The biggest issue using the CLI for me is the vast amounts of decorative characters that Claude code produces. They are easy to filter out using Windows screen readers, but much more difficult to deal with on macOS with Voiceover. I mainly use CC either via the desktop app or via a remote session from claude.ai<http://claude.ai>. That combined with hooks, claude.md rules to produce structured output, and a good set of personal skills have proven to be very effective. I wish Claude code had a flag to suppress those ornamental characters in the CLI though.

On Jun 11, 2026, at 1:54 PM, glenrgordon @.***> wrote:

[https://avatars.githubusercontent.com/u/18452241?s=20&v=4]glenrgordon left a comment (anthropics/claude-code#11002)<https://github.com/anthropics/claude-code/issues/11002#issuecomment-4683425467>

I’ve not tried Claude Sonar because of what it’s documented as doing: filtering command output. Unless I’m misunderstanding things, Claude will also see this filtered output. Great for screen reader users, not so great for Claudetaking action based on the output, especially if what gets summarized away might actually be relevant.

I’d be happy if someone can disabuse me of my understanding.

--Glen

From: StigJoe @.***>

Sent: Thursday, June 11, 2026 11:14 AM

To: anthropics/claude-code @.***>

Cc: glenrgordon @.>; Mention @.>

Subject: Re: [anthropics/claude-code] [FEATURE] Add a --screen-reader mode for better accessibility with NVDA and JAWS (Issue #11002)

<https://avatars.githubusercontent.com/u/264944309?s=20&v=4> StigJoe left a comment (anthropics/claude-code#11002) <https://github.com/anthropics/claude-code/issues/11002#issuecomment-4682597388>

I'm a developer who uses Claude Code daily and I want to help make CLI

coding agents usable with screen readers. I came across claude-sonar

(github.com/vylasaven/claude-sonar) — a hooks-based plugin that reformats

tool output into screen-reader-friendly summaries with optional TTS. It's

quite complete (~500 tests) but unpublished and no longer actively

maintained.

I'm considering picking it up: hardening it, publishing it to npm, and

extending it beyond Claude Code (Codex CLI, Gemini CLI, Aider) plus the

harder unsolved parts like accessible diffs and agent-status cues.

Before I build in the wrong direction, I'd really value input from people

who actually use screen readers:

1. What's the single most painful part of using Claude Code (or other AI

CLI tools) with a screen reader right now?

1. Would a maintained version of something like claude-sonar be useful to

you?

1. Would anyone be open to being an early tester / co-maintainer? I want

to build this with screen-reader users, not for them.

Thanks — happy to go wherever is most useful.

—

Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/11002?email_source=notifications&email_token=AEMY6EIWO722VRGXKHHYIUT47LLFLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRYGI2TSNZTHA4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4682597388> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEMY6EK5TJ4IILLY4KQQR5L47LLFLAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TGNJYG44TGMJZGEY2C5QC> .

You are receiving this because you were mentioned. <https://github.com/notifications/beacon/AEMY6EOYX3WUONW4E2DHXAT47LLFLBFCNFSM6AAAAACLEKF6NCWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTYAAAAACFY2YQGKM4TFMFZW63VHNVSW45DJN5XA.gif> Message ID: @. @.> >

—

Reply to this email directly, view it on GitHub<https://github.com/anthropics/claude-code/issues/11002?email_source=notifications&email_token=AJH5KGRQP5MCUIR7YYYUZ7347LW37A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRYGM2DENJUGY32M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4683425467>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJH5KGVMOMOSMDIVAXSHPO347LW37AVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TGNJYG44TGMJZGEY2C5QC>.

You are receiving this because you were mentioned.Message ID: @.***>

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

As a blind developer and CS student, I use Claude Code also regularly, and rely primarily on Braille rather than speech. For me, the biggest problem is currently the fact that sometimes, e.g. in plan moden when Claude asks questions or when it asks for the permissions to use a tool, console is rebuilding or changing things in the output while awaiting my interaction. That often makes the Braille display jump between lines while I'm currently reading what I'm actually asked. Of course I know the switch to untether cursor from system which NVDA screenreader provides, but not every screenreader allows it this way. Also there are NVDA addons breaking this functionality, so it is not always given.

@glenrgordon Fair question — so I went and read the source (and the
Claude Code hooks docs) rather than sonar's README. Two findings:

1. Sonar's entire hook output type is:

hookSpecificOutput?: {
hookEventName: string;
additionalContext?: string;
decision?: PermissionDecision;
}

Per the Claude Code docs, additionalContext is inserted into the
conversation as an additional system reminder — the model still
receives the full, unmodified tool_response. The significance/
filtering logic only decides what gets spoken (TTS/earcons).

1. More decisively: the hooks API itself has no mechanism to replace

tool output. The only fields that modify anything are updatedInput
on PreToolUse / PermissionRequest — tool inputs, before execution.
A PostToolUse hook couldn't filter what Claude sees even if it
wanted to.

(One honest caveat: sonar can optionally auto-approve/deny
permission prompts via configured rules — behavioral, opt-in, and
also doesn't touch tool output.)

So the concern doesn't apply — but your reading of the README was
reasonable: it literally says "Claude gets a summary" and "silently
summarized for Claude," which is misleading. That deserves a docs fix.

@kellylford @fcnjd @rperez030 — thank you, this is exactly what I was
hoping to learn, and it's changing my priorities. What I'm hearing:

1. The worst pain is the TUI constantly rewriting the screen — echo

storms for speech users, Braille displays jumping lines mid-read
during plan/permission prompts. That's a renderer problem: no output
filter can fix it; it needs upstream fixes or a PTY-level wrapper.

1. Decorative characters are a major issue, especially on VoiceOver

where they're hard to filter.

1. Summarization is contested — useful for some speech users, actively

unwanted by others. Several of you would rather have raw-but-clean,
stable output than summaries.

So: clean & stable first (strip ornaments, change nothing else),
summaries strictly opt-in. And a presentation-layer filter never sits
between the model and its tool results, so the concern above wouldn't
apply to that approach by construction.

One question, especially for Braille users: if output were linear and
stable (no re-renders), does that get you most of the way — or is the
interactive prompt UX (plan mode / permission menus) the bigger blocker?

@StigJoe Than you for checking the Sonar readme. I can only speak for myself, but to answer your question: Actually what was described above regarding re-rendering when you type text was something I on my Braille display didn't even notice. The initial problem here was more the cursor placement, but that was fixed already several months ago, issue #39900. In my case, it is more the changing output during interactive sessions, like the plan mode. It's not always the case, sometimes in plan mode output stays static as well. But could imagine that e.g. a subagent is working in the background and doing things, and that leads to content changes sometimes.

I'm a blind developer using VoiceOver on macOS, and Claude Code has genuinely transformed how independently I can work. Backend development that used to require a lot of trial and error with a screen reader is now something I can do fluidly through the CLI, and I wanted to add my voice to this request because I think the change being asked for here would make a substantial difference for blind developers specifically.

The friction point is the terminal UI chrome that Claude Code draws around tool calls and results: connector glyphs like the box-drawing corner character before tool output, long horizontal separator lines made of dash characters, and the prompt cursor symbol. None of these carry information for a screen reader user, but VoiceOver still has to read or attempt to pronounce them, and on long separator lines that means sitting through a string of "dash dash dash" repeated dozens of times before getting to the actual content. Animated spinners during streaming responses add to this, since each frame update can trigger another announcement, producing a kind of fluttering noise that makes it harder to tell when something useful has actually happened.

None of this is about removing functionality or visual polish for sighted users. It would be enough to have an opt-in mode, perhaps the screen-reader flag already proposed in this issue, that omits purely decorative box-drawing and separator characters and reduces spinner-driven announcements, while keeping all the actual structural and informational content intact. For someone using a screen reader, that single change would remove most of the remaining noise between me and the information I actually need.

I want to be clear that this comes from a place of real enthusiasm for the tool, not frustration. Claude Code already gives blind developers a level of independence in coding work that most tools don't come close to. Closing this gap would make it dramatically better for what is, for many of us, becoming an essential part of how we work.

@BlindCraigCoding
As far as I can tell there's still no built-in flag or setting that strips the decorative characters. The reason it's hard is architectural. Claude Code's UI is drawn with Ink, which renders to a terminal character grid and updates it in place with ANSI escapes rather than emitting a line-by-line stream. So the box-drawing and separators are hard to remove cleanly from either side: a simple output filter on stdout just sees a mess of escape sequences, and a screen reader reading the terminal buffer ends up re-reading the repainted grid. The one layer where you can actually linearize it is a PTY in the middle running a headless terminal emulator that diffs the cells.

@digitalby has already built an early proof-of-concept along exactly that line — a small PTY wrapper for Claude Code (accessible-claude-code). I want to be honest that it's genuinely early (alpha/PoC, macOS-first, and it uses the say command rather than routing through VoiceOver directly), so it's not something I'd call usable yet — but it's the first thing I've seen taking what I think is the architecturally right approach, so it seemed worth flagging.

What I don't see mentioned in these discussions (although the thread is quite large, so sorry if I missed anything) is that Anthropic did recently add a scantily-documented screen reader mode setting (look for axScreenReader).

As a screen reader user, my impressions are mixed; the removal of needless Unicode glyphs and visual decorations is great, having to confirm menu selections with enter is not so great, and some menus (notably settings) still don't provide proper hardware cursor navigation. The input line still re-renders on every character instead of printing just that single character to the TTY, the "thinking" status bar re-renders every couple of seconds, just to show how long Claude has been thinking for (which is overkill IMO), and there's still some unicode here or there. It's moving in the right direction, but quite far from a satisfactory experience.

for the MacOS users out there: VoiceOver in Terminal will not provide you with a great experience by any means. What you should be using instead is tdsr, which is a proper terminal screen reader with speech queuing, cursor tracking management options and such.

Hi everyone, thank you so very much for all your feedback ❤️

We built a screen reader mode for the Claude Code CLI. You can enable it with claude --ax-screen-reader starting with v2.1.181. I recommend using the latest edition rather than stable. You'll find more bug fixes in latest.

Please note: this is not officially released yet, it is still very much in testing and there may still be bugs & missing features. In fact it's not just possible but probable that there are more bugs. We're putting this out early because we think it's a much more accessible experience but we're still working on the rough edges.

Here's what you can expect:

1. It swaps the visual interface for plain, linear text that screen readers can follow.
2. Hides decorative borders, spinners, and animated glyphs (or swaps them for a text equivalent).
3. Labels each prompt with you: and response with claude:. This should help with search.
4. Menus become numbered lists. Type the number and press Enter.
5. Yes/no questions can be selected with the y / n keystrokes.
6. Tool calls, permission prompts, and cost summaries get short spoken-friendly prefixes (tool:, Permission Required:, Cost:).
7. Rings the terminal bell when it's your turn, i.e. when Claude finishes responding, when it needs a permission decision, or when a long tool call completes.
8. The "tool running" indicator is static and hidden from screen readers. No more pulsing-dot chatter.
9. The elapsed-time / token-count line is frozen so it's not re-announced every second.
10. Emits prompt markers at turn boundaries so your terminal's native "jump to previous prompt" shortcut works (OSC 133 works in iTerm2, VS Code, Windows Terminal, Kitty, Ghostty). FYI this does not apply to the default terminal app on e.g. macOS.

Hey @georgez-a11y, great work, we appreciate this!

However, I think there are still a few things worth looking into:

1. Currently, the entire input line re-renders on every keystroke. Some screen readers don't like this, and re-read the entire line instead of reading just the typed character.
2. Some of the more complex UI panels would benefit from more screen reader polish. The plugins panel is a good example; it still uses a Unicode cursor indicator instead of the terminal hardware cursor to indicate the user's position.
3. Could you explain why screen reader mode requires us to press enter after typing a number to select a menu option? For menus where the number of options is less than 10 (and so only a single digit is necessary to choose one unambiguously), this adds an extra keystroke. The same applies to y/n prompts.
4. Many screen readers can handle arrow-key-based menu navigation just fine, as long as the user's current position is indicated by the hardware cursor, not by color or a a character-based indicator. While number-based menu navigation is genuinely useful and speeds things up in many scenarios, there's nothing wrong with arrow keys as long as they're implemented properly. I believe that the root cause of why the previous / non-screen-reader menu system didn't work that well for SR users wasn't that it was based on arrow keys, it was that cursor rendering was not implemented in a way screen readers expect.
5. I think SR users would benefit from a startup prompt asking them whether they want to use CC in screen reader mode or not. There's already one for choosing a terminal theme, you could add a "press s to enable screen reader mode" prompt there. You could also go the Powershell route and auto-enable it when a screen reader is detected, though keep in mind that such an approach fails when Claude Code is used on a headless computer over ssh, which isn't an uncommon setup.

Overall, I believe that steps in the right direction have been made here, and it's very nice to see that Anthropic is paying attention to this issue.