You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I searched existing issues and did not find a duplicate.
I am describing a concrete problem or use case, not just a vague idea.
Area
apps/web (equally affects apps/desktop, which hosts the same terminal)
Problem or use case
I'm a screen reader user on Windows (NVDA is my primary screen reader), and I can't read or effectively write in the T3 Code terminal.
The terminal renders to a canvas that is marked aria-hidden, so its content never reaches the accessibility tree. Concretely, with a screen reader running:
Command output can't be read at all — not streamed as it arrives, and not reviewed afterward. There is no way to know what a command printed, whether it succeeded, or what the shell prompt is asking.
Typed input can't be reviewed either; the input field the screen reader lands on always reads as empty.
There's no non-visual indication of which terminal session is active when multiple exist.
This makes the terminal — a core surface of the product — effectively unusable without sight. The surrounding app is largely navigable; the terminal is the hard wall.
Proposed solution
Make terminal content available to assistive technology. Prior art suggests two complementary pieces:
A readable buffer: some way to get the terminal's text (including scrollback) into a real, focusable text surface that a screen reader can navigate with standard commands — the approach VS Code landed on with its "accessible view" (Alt+F2) after other approaches failed.
Non-visual notification of important events (e.g., command completed, with exit status) so users know when there's something worth reading, without narrating every line of streaming output.
I'd suggest treating VS Code's terminal accessibility as the reference implementation — it's well documented, and its design history (microsoft/vscode#98918) is explicit about what worked and what didn't for NVDA/JAWS users.
Why this matters
Blind and low-vision developers currently cannot use T3 Code for any workflow that touches the terminal. Fixing this opens the product to screen reader users entirely, and the eventing/announcement groundwork would benefit other parts of the app too.
Smallest useful scope
A single command/keybinding that presents the current terminal buffer as plain, screen-reader-navigable text (even read-only, even without live updates). That alone would take the terminal from "no access" to "usable with effort."
Alternatives considered
Running commands in an external terminal (e.g., Windows Terminal, which has good screen reader support) — loses the integration with threads/agents that is the point of the product.
Copying terminal contents to the clipboard to read elsewhere — not currently possible non-visually, since making a selection requires seeing the buffer.
Risks or tradeoffs
Accessibility-tree updates for fast-streaming output have real performance costs; updates need batching/throttling.
Screen reader behavior differs between the browser and the Electron desktop app, so verification needs to happen in the shipped desktop build.
This discussion was converted from issue #5500 on August 15, 2026 09:48.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Before submitting
Area
apps/web (equally affects apps/desktop, which hosts the same terminal)
Problem or use case
I'm a screen reader user on Windows (NVDA is my primary screen reader), and I can't read or effectively write in the T3 Code terminal.
The terminal renders to a canvas that is marked
aria-hidden, so its content never reaches the accessibility tree. Concretely, with a screen reader running:This makes the terminal — a core surface of the product — effectively unusable without sight. The surrounding app is largely navigable; the terminal is the hard wall.
Proposed solution
Make terminal content available to assistive technology. Prior art suggests two complementary pieces:
I'd suggest treating VS Code's terminal accessibility as the reference implementation — it's well documented, and its design history (microsoft/vscode#98918) is explicit about what worked and what didn't for NVDA/JAWS users.
Why this matters
Blind and low-vision developers currently cannot use T3 Code for any workflow that touches the terminal. Fixing this opens the product to screen reader users entirely, and the eventing/announcement groundwork would benefit other parts of the app too.
Smallest useful scope
A single command/keybinding that presents the current terminal buffer as plain, screen-reader-navigable text (even read-only, even without live updates). That alone would take the terminal from "no access" to "usable with effort."
Alternatives considered
Risks or tradeoffs
Examples or references
Contribution
All reactions