Repository navigation
Screen readers cannot access streaming assistant content while a response is generating #33137
Description
Description
Summary
While an assistant response is being generated, the assistant content container is marked with aria-hidden, which removes the streamed content from the accessibility tree.
As a result, screen reader users can hear generic status updates such as "Thinking..." but cannot access the actual assistant content, tool activity, reasoning summaries, search progress, or streamed output that is visible on screen.
Technical Details
The assistant content container is rendered with:
aria-hidden={workingTurn(assistantPartRow().userMessageID)}When the turn is generating, the content is removed from the accessibility tree.
Removing this attribute allows screen readers to access streamed content during generation.
Environment
- OS: Windows
- Screen Reader: NVDA
Additional Notes
This issue affects accessibility for screen reader users because important information is visually available but not programmatically exposed during generation.
Plugins
No response
OpenCode version
OpenCode Desktopv1.17.8
Steps to reproduce
- Open a conversation and submit a prompt that triggers a streamed response.
- Use a screen reader such as NVDA.
- Navigate through the page while the response is being generated.
- Observe that only status information is exposed while the assistant content remains unavailable.
Expected Behavior
Screen reader users should be able to access the same streamed assistant content that sighted users can see while generation is in progress.
Actual Behavior
The streamed assistant content is hidden from the accessibility tree until generation completes.
Screenshot and/or share link
No response
Operating System
Windows 10 22H2
Terminal
No response
Activity
abdullahsaad27 commentedon Jul 22, 2026
Quick investigation: the actual file Desktop renders is
packages/app/src/pages/session/timeline/message-timeline.tsx, notpackages/session-ui/src/components/session-turn.tsxthat PR #33139 targeted (that one is only used in the enterprise share page).message-timeline.tsxhas the same two patterns:aria-live="off"onsession-turn-message-contentaria-hidden={workingTurn(assistantPartRow().userMessageID)}onsession-turn-assistant-contentTested locally with NVDA on Windows: replacing
aria-hiddenwitharia-busyand changingaria-liveto"polite"makes the streamed content appear in the accessibility tree during generation without affecting visual rendering. Content becomes readable during streaming (full live-region auto-announce with text-delta debounce is a separate enhancement, but content is no longer hidden).This fix is ARIA-only — no visual impact for sighted users.
Opening a PR targeting the correct file shortly.
aimansour commentedon Sep 12, 2026
@ashu-choudhury, the current-
devfix is up in #48597 with an ARIA-snapshot regression test that fails on the existingaria-hiddenbehavior. If you can verify it with NVDA, your feedback would be valuable. If it resolves your case, please also leave a 👍 or ❤️ on the PR—the repository cleanup job uses positive reactions to keep older contributions open.thdxr commentedon Oct 11, 2026
Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (
opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
aimansour commentedon Oct 12, 2026
The same
aria-hiddenbarrier is still present in the V2 renderer atv2@4617210822bdbb31e5749751afbfb4584ccedac8, and in currentdev(identical affected file). The migration closure did not correspond to a merged fix.Opened #54652 as the current V2 tracking issue, with source links and the affected version. PR #51084 is the existing fix; it now references that open issue. The separate AnimatedNumber defect reported in #41408 is tracked in #54653.
ashu-choudhury commentedon Oct 23, 2026
Bro, honestly, I'm fucking done with this.
I don't even believe this issue will ever be resolved anymore. I've completely lost my patience with this project. We report accessibility issues, developers investigate them, PRs are created, and then what? The same problems keep coming back, issues get closed, and we're expected to move on as if nothing happened.
Look at the number of open issues and pull requests in this repository. Thousands of issues, more than a thousand PRs, and so many accessibility problems still sitting there. What the hell is actually happening here?
And the GitHub bot? I genuinely don't understand what the hell it's doing anymore. It feels like everything is being closed, removed, or pushed aside while actual problems remain unresolved. I don't know what the bot is thinking, and honestly, I'm tired of trying to understand it.
This isn't some stupid cosmetic bug. I'M BLIND. I USE A SCREEN READER. When you hide the assistant's response from the accessibility tree, you're literally preventing me from accessing content that other users can already see. How is that acceptable in a modern development tool that uses AI?
We even had developers investigate this problem, discuss fixes, and work on PRs. And now we're back here again, with the same fucking problem in V2. The original issue gets closed because development has moved forward, but the accessibility problem hasn't magically disappeared just because you've released a new version!
WHAT IS THE POINT OF ALL THIS?
Honestly, sometimes I feel like reporting accessibility issues in this project is a complete waste of time. You spend your time explaining the problem, following discussions, checking PRs, and hoping something will finally change. And then you end up exactly where you started.
I know this repository has a massive number of issues. I know maintaining a project this large isn't easy. But that doesn't mean accessibility should keep getting pushed aside while everyone moves on to the next feature.
And the whole AI thing? What the hell is the point of building AI-powered development tools if blind developers can't even properly access the AI's responses? You want people to use your software to build the future, but some of us can't even use the basic interface independently.
I'm genuinely exhausted. I'm frustrated, disappointed, and completely done with this entire situation.
At this point, I'd rather use proprietary software than keep wasting my time on an open-source project where I can't even trust that fundamental accessibility problems will be fixed. At least with another tool, I might actually get work done instead of spending my time fighting the interface itself.
I don't care anymore whether this comment sounds rude. I'm tired of pretending that this situation is acceptable.
I'm done reporting the same problems. I'm done waiting for fixes. I'm done following endless discussions and PRs just to see the same barriers remain.
I genuinely don't believe this issue will ever be properly resolved, and I've lost the motivation to keep fighting for it.
Good luck with the project. I'm done.
aimansour commentedon Oct 26, 2026
@ashu-choudhury I’m blind and use a screen reader too, and I’m struggling with the same barrier. I understand why you’re exhausted: content that is already visible should be available to us while the response is still generating.
I opened #54652 to keep this tracked after the V1 issue closures, and the fix is in PR #51084. I’m updating it against current
dev, checking the regression tests, and will test it manually with my screen reader as well. I haven’t given up on this—I’ll keep following up and working through review until the fix is merged upstream. You’re not the only one dealing with this, and you’re not fighting it alone.ashu-choudhury commentedon Oct 26, 2026
@aimansour Best of luck