The prototype concerns the running-task footer in UseAgent issue #338. Its source snapshot is pinned to upstream commit 9be3a7f96699feb9a83b7cd6179d326d27567d20.
In that snapshot, the footer wrapper carries role="status" and contains a self-updating elapsed timer. The prototype moves the status role onto the phase/step sentence. The phase remains available in a visually hidden span; the timer, run-details trigger and Stop control remain outside the status region.
The recorded checks cover three different boundaries:
- Regression tests: two new tests fail against the original component and pass with the patch. The focused footer/phase set reports 30 passing tests. The checks cover the status region's text and keep timer/control labels outside it while preserving phase changes.
-
Browser DOM observation: in the upstream session component lab, elapsed time advanced from 1m 57s to 2m 29s while the live text stayed
Working. Editing gateway/routes.ts. The region contained no timer or buttons. The lab used synthetic fixtures and a local fixture API, without real account data or model calls. - Wider validation: frontend TypeScript and lint passed, with existing lint warnings. The full frontend suite reported 1,695 passes and one Ghostty/WASM URL failure; that failure was also reproduced with the original production component restored.
These results establish properties of the test setup and observed DOM. They do not establish what VoiceOver or NVDA actually announces. Manual assistive-technology testing and a signed-in agent run remain outstanding. Full root checks and a successful production build are also outstanding: build attempts encountered Google Fonts connectivity and a Turbopack worker-port permission error.
The pinned source bundle, patch and reproduction notes preserve the upstream attribution and AGPL-3.0-only license. This report links to that source rather than reproducing its code. The prototype is not an accepted fix or a completed accessibility verification.
Top comments (1)
Good that the report says outright what the tests don't prove. One case I'd add for the manual screen reader pass: when the phase sentence changes, check that it's announced once, not twice. The visually hidden span plus the visible text can end up read as duplicates if both sit inside the live region.
And the opposite check: leave the phase unchanged for a minute while the timer runs, and confirm nothing is announced at all. That's the behaviour the move was meant to give, and it's the one a DOM test can't show.