Accessibility story for docking windows — investigation needed

[codemonkeychris]

Context

While fixing #419 (E2E test reliability for tab tear-off), we hit a class of failures that points at a deeper concern than just the tests:

• Cross-window UIA interactions break mid-drag. When the source floating window is hidden mid-tear-off (BeginFloatingTearOff → AppWindow.Hide() on the single-tab path), WinAppDriver's UIA-driven input pipeline freezes — subsequent moves never reach the host's overlay handlers. Detailed Tracker.OnTick / Overlay.PointerEntered tracing confirmed the cursor moves at the OS level but the host's WinUI input dispatch isn't seeing the events.
• Dragged-preview window opacity bypasses WinUI's hit-test logic, not UIA's. WS_EX_TRANSPARENT makes the OS WindowFromPoint skip the preview, but UIA's tree walkers still see the preview as a top-level window covering the cursor. The same mechanism that breaks tests would break a screen reader trying to announce or interact with the drop target underneath.

If UIA-driven automation (which is essentially what an assistive technology IS) can't drive a float → host dock-back, neither can a JAWS / NVDA / Narrator user. We have a tested-and-shipping feature (#418) whose primary input modality is not accessible.

What this issue is for

Track the investigation — not the implementation. Specifically:

1. Audit our existing UIA surface for the docking pipeline. What does the UIA tree look like during an active drag? Are drop targets named/announced? Can a user identify available targets without seeing them?
2. Research how other docking-window solutions tackle accessibility. Concrete candidates:
   • Visual Studio's docking (likely the gold-standard reference — it's where the §2.6 design came from)
   • JetBrains Rider / IntelliJ tool windows
   • VS Code's drag-drop panel
   • AvalonDock (WPF, open source — should have visible AT story)
   • Telerik / DevExpress / Syncfusion docking controls
   • WinUI 3 NavigationView's pane-positioning APIs (closest first-party analog)
3. Identify what an accessible alternative input modality looks like. Likely candidates:
   • Keyboard-driven move/dock (already partially present — keyboardOverlayActive references in DockHostNativeComponent.cs). Is the existing keyboard-overlay flow discoverable / announced?
   • A context-menu action for "Move to floating window" / "Dock to ...".
   • An ARIA-equivalent live-region announcement strategy during drag.
4. Decide what we owe the user before we promote this feature beyond Phase 0.

Out of scope (for now)

• Implementation. This is an investigation issue. Once we have a recommended approach, we'll spin off the implementation work as separate tickets.
• The E2E Appium tests for tab tear-off — finish cross-window drag (E02/E03/E04) #419 E2E tests themselves — those landed via test(045): tear-off E2E suite reliable under WinAppDriver (#419) #426 with the WinAppDriver-tractable scenarios green; the cross-window paths the AT story would need are covered today only by synthetic-event selftest fixtures.

Related

• feat(045): VS-style immediate tab tear-off pipeline #418 — tab tear-off pipeline (the feature)
• E2E Appium tests for tab tear-off — finish cross-window drag (E02/E03/E04) #419 — E2E test reliability investigation (where this gap surfaced)
• test(045): tear-off E2E suite reliable under WinAppDriver (#419) #426 — PR that landed the 4/4 reliable E2E suite + documented the cross-window UIA limitation

Acceptance criteria

A markdown doc in docs/specs/045/accessibility-investigation.md (or similar) that:

• Surveys the 3-5 most relevant docking implementations + their AT approaches.
• Recommends an accessibility story for our docking surface (or escalates if there's no clean answer).
• Lists the follow-up tickets needed to implement it.