[Repo Assist] A11y: expose tool-output body in automation subtree for CompactSummary#608
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:44 PM ET / 01:44 UTC. Summary Reproducibility: no. high-confidence runtime reproduction was established here. Source inspection confirms the body is a sibling outside the header Button subtree, but no current-main or PR-head Narrator/UIA proof is attached. Review metrics: 2 noteworthy metrics.
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: Expose the expanded body in a way that preserves per-step UIA descendants, then land only with current full validation and redacted Narrator/UIA tree proof showing the header and rows are discoverable. Do we have a high-confidence way to reproduce the issue? No high-confidence runtime reproduction was established here. Source inspection confirms the body is a sibling outside the header Button subtree, but no current-main or PR-head Narrator/UIA proof is attached. Is this the best way to solve the issue? Unclear as written. The header button label is plausible, but naming the body wrapper conflicts with existing local UIA guidance unless the PR proves descendant step rows remain visible. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model gpt-5.5, reasoning high; reviewed against eb06fba21c44. Label changesLabel 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
|
clawsweeper
Bot
added
rating: 🧂 unranked krab
|
🤖 This is a note from Repo Assist. PR #650 (Fix tool output accessibility labels) by Suggesting this PR (#608) 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
Closes #590
Fixes the accessibility regression where the tool-output body content was rendered in a
Borderelement that sat outside the headerButton's automation subtree inCompactSummarymode. Screen readers and automation tools could navigate to the header button but could not discover the expanded body content.Root Cause
In
CompactSummarystyle, the tool-burst UI builds aheaderButton(aButtonelement that toggles collapse/expand) and separately appends a bodyBorderas a sibling. Because the body was a sibling of the button rather than a child, it was invisible to the button'sAutomationNameand was not reachable via UI Automation's control tree when the button was the interaction target.Fix
AutomationNameon theheaderButtonreflecting the current expanded/collapsed state (e.g.,"Expand tool steps: <summary>"/"Collapse tool steps: <summary>").AutomationNameon the bodyBorder("Tool steps for: <summary>") so it is independently accessible even when it sits outside the button's subtree.These two names give screen readers unambiguous labels for both the toggle target and the expandable content region.
Test Status
set_env_*) in this runner environment. This is a pre-existing infrastructure issue unrelated to this change (no C# compiler errors).