[BUG] macOS desktop app: VoiceOver cannot read assistant responses (no announcement, transcript unreachable) — apparent recent regression

Summary

In the Claude desktop app on macOS, a VoiceOver user can type and send messages normally, but cannot read the assistant's responses at all through VoiceOver. New responses are not announced when they complete, and the response text in the conversation transcript is not reliably reachable by VoiceOver navigation. Input works; output is effectively invisible to the screen reader.

This appears to be a recent regression: the same setup worked in prior sessions, and the behavior changed with no desktop-app update in roughly the preceding 12 hours — which suggests a server-side rendering change or a change in how the transcript is constructed, rather than a new app binary.

I am a fully blind software engineer and use VoiceOver full-time. This is reported from real daily use, not a lab test.

Environment

• Claude desktop app: 1.15962.0
• macOS: 26.5.1 (build 25F80)
• Hardware: Apple Silicon (M-series)
• Screen reader: VoiceOver
• (For contrast: Claude Code CLI 2.1.191 is also installed, but this report is about the desktop app.)

Steps to reproduce

1. With VoiceOver running on macOS, open the Claude desktop app.
2. Type a message into the input field and send it (this works correctly — input is accessible).
3. Wait for the assistant to respond.
4. Try to read the assistant's response with VoiceOver.

Expected

• When the response finishes generating, VoiceOver announces it (the conversation transcript behaves as an ARIA live region, or the equivalent is exposed on macOS).
• The response text is present in the accessibility tree and is straightforward to navigate to and read with normal VoiceOver commands.

Actual

• Nothing is announced when the response completes.
• The response text cannot be read in the desktop app via VoiceOver — neither auto-announced nor reliably reachable by navigation. From the user's perspective the assistant's replies simply aren't there.
• The only way to read responses is to switch to the Claude iPhone companion ("remote") app, and even there it is painful: nothing is auto-announced, so the user must manually navigate into the chat and scroll all the way to the top to read down. Typing input on the Mac while reading output on a phone is not a workable long-term workflow.

Impact

This effectively locks blind / VoiceOver users out of the macOS desktop app — a population that has been actively adopting Claude. When responses can't be read, the product is unusable for them regardless of how good the model is.

Current workaround (out-of-band)

As an interim measure, responses are being spoken aloud out-of-band using the macOS say command (driven externally, at an elevated speaking rate, since blind users typically listen far faster than default TTS). This is exactly what feature request #58429 asks the app to do natively. It confirms the gap is real and that a built-in spoken-response option would directly address it — but it does not fix the underlying problem that the transcript is not exposed to VoiceOver.

Related issues

• #70000 — Screen reader: no announcement when response is generating or complete (Windows/NVDA). This report is the macOS/VoiceOver counterpart, plus the apparent regression.
• #58428 — [A11y bug] Missing heading semantics and "response complete" announcements in desktop app (macOS; closed/stale). This may be the same underlying issue resurfaced or worsened.
• #69996 — Screen reader accessibility friction: heading structure, ARIA landmarks, focus management (Windows desktop).
• #58429 — [A11y feature request] Built-in option to speak Claude's responses aloud (the workaround above, natively).

Notes for triage

• Suggested labels: bug, platform:macos, area:a11y, area:desktop, and likely regression.
• Because there was no app update in the relevant window, please check recent server-side / web-view rendering changes to the conversation transcript for a missing/removed live region or a change that dropped response text out of the accessibility tree.
• Happy to provide further detail, test candidate fixes on-device, or capture an Accessibility Inspector trace if that would help.