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:
- 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.
Examples or references
Contribution
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