Screen Reader Accessibility for Unicode Symbols

Huge +1 to this with thanks in advance.

The unicode symbols can also cause issues in certain terminal emulators like Emacs EAT, where they can cause layout issues if the font does not contain the unicode character and a fallback font is used.

This also causes issues in Claude Code Emacs wrappers like this issue in my claude-code.el package.

There are workarounds, but an option to have a plain ascii CLI would make Claude Code more accessible for screen readers and other programs.

+1 to this. A related issue: there isn't a way to use + and - to indicate additions / deletions in diffs, and it seems to only be indicated by colour.

+1 on this issue. I'm currently using a brittle workaround and clunkily formatting the text and displaying on text document, with replacing all the unicode symbols with spaces or plain characters, but not ideal.

Also I created a new GitHub issue for the other thing mentioned in this thread about showing code diff with +/- in addition to font color changes, because I have no workaround for that currently:
https://github.com/anthropics/claude-code/issues/942

For Emacs in vterm, I had to use this workaround because my monospace font had varying widths for these Unicode glyphs:

```emacs-lisp
(defun diego--vterm-font-setup ()
"Configure font settings specifically for vterm buffers, workaround claude-code."

;; Apply ASCII replacements for vterm specifically
(let ((tbl (or buffer-display-table (setq buffer-display-table (make-display-table)))))
(dolist (pair
'((#x273B . ?*) ; ✻ TEARDROP-SPOKED ASTERISK
(#x273D . ?*) ; ✽ HEAVY TEARDROP-SPOKED ASTERISK
(#x2722 . ?+) ; ✢ FOUR TEARDROP-SPOKED ASTERISK
(#x2736 . ?+) ; ✶ SIX-POINTED BLACK STAR
(#x2733 . ?*) ; ✳ EIGHT SPOKED ASTERISK
))
(aset tbl (car pair) (vector (cdr pair))))))

(add-hook 'vterm-mode-hook #'diego--vterm-font-setup)

following up to better understand the issue so i can help fix - other than ✻ what are the specific unicode chars that are hard on screen readers? thanks!

Just for context, a screen reader reads characters left to right. If it’s a word, it’ll read the word, word by word. We can scroll through lines to read a particular section of a terminal stdout.

In claude code, the stdout includes many lines and beginning of lines with unicode characters, similar to stdout generated using say a cli package like uv/typer:

The screen reader reads these as a bunch of descriptive icon like characters like “vertical oblique blah blah” and repeats across the entire line.

This is because the unicode gives some sense of visual spatial separation but for screen reader users, this is totally spurious and unnecessary stuff we could do without.

I’ve stopped using claude code for this. I don’t have time to sift around all this unicode stuff.

On 26 Oct 2025, at 07:01, karenzhou-ant @.> wrote: karenzhou-ant left a comment (anthropics/claude-code#247) following up to better understand the issue so i can help fix - other than ✻ what are the specific unicode chars that are hard on screen readers? thanks! — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.>

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.

This issue is ongoingSent from sputnik7 On 8 Dec 2025, at 8:20 PM, github-actions[bot] @.***> wrote:github-actions[bot] left a comment (anthropics/claude-code#247)
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.

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

This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.