fix(a11y): expose streaming assistant content to screen readers - #38393

Filing a related request that builds on this work: #39368. It asks for the same kind of TUI-level screen-reader affordances, plus persistent toggles for the banner, animations, status footer, and the alternate screen buffer so a screen reader user can opt into a clean linear experience. Worth a look when reviewing the a11y surface area — happy to coordinate or split out any subset if it helps.

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.

Hi! Could this PR be reopened? It was closed by the cleanup bot due to age, but it's an essential accessibility fix for screen reader users (NVDA) on Windows. It fixes aria-live and aria-busy in message-timeline.tsx, directly addressing #33137 and serving as a blocker/prerequisite for the a11y work in #39368. Tested and verified locally with NVDA. It would be great to keep this alive.

Honestly, this is a pretty frustrating example of automated cleanup optimizing for PR statistics instead of project quality.

This PR is being treated as disposable because it is “more than 1 month old” and has fewer than 2 positive reactions, even though it addresses a genuine accessibility bug where screen readers literally cannot access streamed assistant content while a response is being generated.

That is not some cosmetic improvement or minor cleanup. For screen reader users, it means a fundamental part of the application is effectively inaccessible during generation. The PR has also already been tested with NVDA and the proposed fix is small, focused, and technically well-motivated.

If a PR like this is sitting without review, the appropriate conclusion shouldn't be “this must be garbage, close it.” It should be “this has not received the review attention it needs yet.”

And yes, I have a personal stake in this issue: I originally filed #33137 myself, and I also opened the related PR that exposed the problems with the previous approach. So I've been following this particular accessibility issue for quite a while.

Closing a genuinely important accessibility fix because an automated bot decided it wasn't getting enough reactions is backwards. If the maintainers don't agree with the implementation, review it, request changes, or reject it on technical grounds. But using inactivity and reaction count as a proxy for technical value is a terrible way to handle accessibility work.

Please reconsider reopening this PR. It deserves an actual technical review.