[Repo Assist] A11y: fix tool-output body outside header Button automation subtree#603
Conversation
… body
In the CompactSummary tool-burst style, the header is a standalone Button
and the expanded body (step rows) is a sibling element outside the Button's
automation subtree. This meant Narrator only announced the button's visual
content (a FlexRow with text nodes that may not compose cleanly) without
context about the task state.
Changes:
- Build a headerAutomationName string: "<summary>, <N step(s)>, <status>,
expanded/collapsed" and pass it to .AutomationName() on headerButton.
Narrator now announces the full card state when the button is focused.
- Add .AutomationName("Tool steps for: <summary>") on the body Border so
scan-mode navigation gives the body region a clear label linking it back
to the task the header describes.
Fixes #590
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Codex review: found issues before merge. Reviewed May 30, 2026, 9:02 AM ET / 13:02 UTC. Summary Reproducibility: no. high-confidence Windows Narrator runtime reproduction was run. The PR defect is source-reproducible: production multi-step tool bursts use Review metrics: none identified. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Mantis proof suggestion Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: Apply the automation relationship or explicit names to the production Do we have a high-confidence way to reproduce the issue? No high-confidence Windows Narrator runtime reproduction was run. The PR defect is source-reproducible: production multi-step tool bursts use Is this the best way to solve the issue? No. The current patch is not the best fix because it labels the inactive/default-off Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found, but no applicable review policy affected this item. Codex review notes: model gpt-5.5, reasoning high; reviewed against eb06fba21c44. Label changesLabel changes:
Label justifications:
Evidence reviewedWhat I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
|
🤖 This is a note from Repo Assist. PR #650 (Fix tool output accessibility labels) by Suggesting this PR (#603) be closed in favour of #650 to avoid confusion. Happy to defer to the maintainer's judgement on which approach to take.
|
🤖 This PR was created by Repo Assist, an automated AI assistant.
Summary
Fixes #590
Root Cause
In the
CompactSummarytool-burst style (multi-step tool calls), the header is a standaloneButtonand the expanded body (step rows) is added as a siblingBorderelement in the outerVStack. This means the body sits outside the Button's automation subtree — Narrator announces the button's visual text content but has no direct link to the body content below it.Fix
Two targeted changes in
OpenClawChatTimeline.cs:Explicit
AutomationNameonheaderButton— builds a string"{summaryLine}, {stepCountLabel}, {taskStatusText}, expanded/collapsed"and passes it to.AutomationName(). When Narrator focuses the header button it now hears e.g. "Searched for files, 3 steps, Done, collapsed, button" — the full card state without needing to navigate further.AutomationNameon the bodyBorder— labels the expanded body region with"Tool steps for: {summaryLine}"so that Narrator scan-mode users who navigate past the button understand what the following content describes.The
Plainstyle (single-step) is unaffected — there the body is already inside the Button's content (VStack(0, headerRow, body)is the button content), so Narrator reads header and body together naturally.Trade-offs
summaryLineis very long, Narrator will read the whole thing. It is capped at 80 chars by the existingTruncate()logic that producessummaryLine, so this is bounded.AutomationProperties.SetLabeledBy(which would be the closest ARIA-equivalent) because that requires resolving both WinUI controls in the same scope, which is awkward in the FunctionalUI reactive rendering pipeline. TheAutomationNameapproach is simpler, fully supported, and sufficient for the stated acceptance criteria.Test Status
.AutomationName()call using the existing FunctionalUI extension already used elsewhere in the file.