[Bug]: Screen readers hear nothing between "Working" and "Done" during a turn

[nibarAhmed]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. Turn on NVDA and open a thread in the T3 Code desktop app.
2. Send a prompt that makes the agent run tools and write a few messages before it finishes.
3. Keep focus in the composer until the turn ends.

Expected behavior

A screen reader user can choose to hear what a sighted user sees in the timeline during a turn: the messages the agent writes while it works, its final message, and, if they want it, what it's doing right now. Whatever they turn off stays silent.

Actual behavior

Since #23752, you hear "Working" when the turn starts and "Done" (or "Failed", "Stopped", "Needs approval", "Needs your input") when it changes state. Nothing in between is announced, and neither is the final message. To find out what the agent did or said, you have to leave the composer and jump back through the message headings.

An earlier version of #23752 also announced activity labels. They were out of scope for that PR, which was narrowed to turn status only, and they were left for a follow-up with a setting (suggestion, reply). They need that setting because they spoke a new label about every 2 seconds, which is too chatty to have on for everyone. In Chromium, NVDA's only way to silence them is NVDA+5 ("Report dynamic content changes"), and that mutes every live region at once: turn status, the sidebar, and error alerts. So these announcements need their own switches in T3 Code (item 5 of #23656).

Impact

Minor bug or occasional failure

Version or commit

main @ 125b619

Environment

Windows 11, T3 Code desktop app, NVDA

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

Leave the composer and use H to jump back through the message headings in the timeline.

Proposed fix (first outline)

I'm a screen reader user, and I'd be happy to work on this. Below is a proposal, not a finished design. Getting the balance between informative and noisy right will take testing with real screen readers, so the details will likely change. Other opinions are welcome, especially from other screen reader users, since preferences differ.

1. Add a screen reader announcements setting in Settings, with one toggle for each kind of announcement:

   Toggle	Default	What it reads
   Messages during the turn	On	Each message the agent writes while it's still working, before the turn ends. Each one is read once it's finished, never token by token, and starts with the author, the same name its heading uses, for example "T3 Code: I'll check the failing test first". It doesn't include the final message.
   Final message	Off	Only the agent's last message of the turn, read once the turn ends, just before "Done". It starts with the author, the same way.
   Activity	On	The current tool or step, for example "Running vp test" or "Reading ChatView.tsx". It's throttled, so only the newest one is spoken.
   Thinking	On	"Thinking" when the agent starts reasoning. The reasoning text itself is never read, and stays in the timeline for browse mode.

   A message counts as mid-turn when the agent runs a tool after it, and as the final message when the turn ends after it. With both message toggles on, each message is heard exactly once.

2. Turn status from fix(web): screen readers hear when the open thread starts, needs you or finishes #23752 stays on all the time and is not affected by these toggles.

3. Labels should make sense when heard on their own. Today a web search can be read as just its query, for example "Theo Browne t3dotgg opinions TypeScript React Next.js AI coding". It should say what the step is: "Searching for Theo Browne t3dotgg opinions…".

4. Announcements are spoken in order of importance:

   • Turn status goes first.
   • Messages go next.
   • Activity labels are dropped once they're out of date.

   Nothing is spoken after the turn has stopped.

5. Use the same live region and pure-function setup as fix(web): screen readers hear when the open thread starts, needs you or finishes #23752 (threadActivityAnnouncement.ts), so the rules can be unit tested and an announcement never re-renders the timeline.

If this approach doesn't fit how you'd like it solved, I'm open to others and happy to follow your direction.

Related

#23656, #23752