macOS tabs, sidebar controls, and choices are operable through accessibility

[jsmestad]

Type: Feature
Priority: High
Related: #1577, #2825, #3284, #3304, #3308

Delivery links: #3321 covers editor-pane accessibility. #3325 supplies the reusable launched-app regression suite. Picker activation reuses #3284 rather than defining a new route.

What

Give file tabs, workspace controls, Git sidebar controls, and choice overlays explicit accessibility roles, state, and activation actions. Labels and identifiers already exist in some places, but the source does not establish a complete action contract across these surfaces.

Why

A screen reader or desktop agent should be able to discover a named control, understand its current state, and activate it without guessing screen coordinates or replaying keyboard navigation.

Acceptance Criteria

1. File tabs expose distinguishable selection and close actions, stable identity, file name, active state, and modified state. Activating either action performs the same operation exactly once as its pointer equivalent.
2. Workspace controls and Git sidebar rows, section disclosures, and existing bulk actions expose discoverable names, current state, and the actions they support. Actions that are normally revealed by hover remain discoverable through accessibility.
3. Picker results and Actions entries, minibuffer candidates, and completion results appear in labelled choice containers. Clients can identify each offered choice, read selected/marked and available loading/error state, and activate a specific choice.
4. Activation captured before query replacement, result reordering, picker/menu closure, tab closure, or core replacement never applies to a different target. A stale target is rejected or becomes unavailable; it does not fall back to the current selection.
5. Opening, navigating, and dismissing a choice surface exposes appropriate accessibility focus while preserving native query editing, IME composition, ordinary keyboard behavior, and return to the correct prior responder.
6. Inspection of the launched app confirms the actual accessibility roles and available actions, and activation changes the expected file, pane, choice, or local disclosure state. Existing pointer, drag/drop, close, context-menu, and keyboard interactions continue to work.

Developer Notes

Locked decision / finished invariant: Every control in this ticket exposes one explicit activation path shared by pointer and accessibility input, with state read from its existing owner.

Evidence: Tab activation combines a tap gesture with identifiers/labels. Git disclosures use button traits plus a gesture, and Git rows have similar composition. Workspace controls use gestures. Picker construction and result semantics expose display state without activation. Source evidence alone does not prove every gesture-based control is inoperable because SwiftUI can synthesize accessibility behavior; verify the actual tree first.

Approach / ownership:

• Prefer plain-styled Button controls where composition permits. For custom drag/tab composition, provide explicit default or named accessibility actions without nested buttons. Keep selection and close as distinct controls.
• Give containers useful labels and native list/group semantics, and give rows stable identity scoped to the offered content revision. View position alone is not an activation identity.
• Route editor operations through the same consumer-local action/encoder path as pointer input. Frontend actions are exhaustive and cannot disappear silently #2825 owns simplification of that Swift action API.
• Keep frontend-only presentation changes, such as a Git section's collapsed state or showing a local workspace menu, with their current local owner. Do not send these through the BEAM merely because other controls do. Git status separates published data from local editing state #3308 owns Git published-data/local-editing separation.
• BEAM updates own choice selection. Accessibility focus follows that selection while respecting the native query field; there is no second Swift choice model.
• macOS picker rows and Actions entries respond to clicks #3284 owns the picker result/action-menu activation protocol, opaque identities, stale-result rejection, and source effects. Reuse that exact route. This ticket owns accessible discovery, list state, focus, and production AX validation, not a competing picker action protocol.

Required replacement: Replace ambiguous label/trait-only interaction contracts on the enumerated controls with explicit native activation. Remove duplicate pointer-versus-accessibility action bodies. Do not simulate clicks with Down/Enter key sequences.

Preserved foundations: Existing InputEncoder behavior, source-owned picker confirmation and safeguards, native query controls, local disclosure state, tab drag/drop and menus, and the AppKit focus policy.

Steps:

1. Inspect live AX roles/actions for the named controls and record any framework-synthesized behavior.
2. Update TabBarView.swift, WorkspaceIndicatorView.swift, and GitStatusView.swift to share activation closures and expose state and non-hover access.
3. Update PickerOverlay.swift, MinibufferView.swift, and CompletionOverlay.swift with labelled containers, stable target identity, accessible activation, and selected/marked state.
4. Bind accessibility focus to the existing semantic selection and native responder boundaries; extend the relevant SwiftUI and input tests.

Temporal / failure matrix:

Sequence	Required result
Select or close a tab while drag/context-menu support is installed	One intended action, separate close target, no duplicate activation
Change query or reorder choices before action delivery	Exact offered choice is used or stale action is rejected
Open an Actions menu, then change selection	Original action context remains authoritative or becomes invalid
Activate a Git disclosure without pointer hover	Existing local state changes and is readable afterward
Unrelated frame during field editing or IME	Input focus and composition remain intact
Dismiss overlay, close pane, or reconnect	No stale accessibility target or queued focus claim survives

Testing / performance: Extend SidebarViewTests.swift, SwiftUIViewTests.swift, and relevant production overlay/input checks, then inspect and activate controls in the launched app. Run representative tab, Git, picker, minibuffer, and completion paths. Check large offered result windows with the existing bounded/lazy layout; accessibility must not eagerly instantiate every project candidate. Existing row-window and invalidation checks remain in force.

Decision coverage / dependencies: All enumerated control families, explicit activation, observable state, stale identity, and focus behavior are required here. The picker portion requires #3284's activation contract; tabs, workspace, and Git controls can start independently. Consume #3304 if it lands first and do not create a parallel focus policy. Whole-app VoiceOver coverage outside these controls remains with #1577. Native action semantics must not be reimplemented by accessibility adapters.

Stop conditions: Do not declare completion from ViewInspector labels alone, hide hover-only actions from assistive clients, introduce nested selection/close buttons, or accept positional picker activation after results change. If a standard control conversion alters drag, menu, IME, or responder behavior, retain the working composition and supply explicit accessibility actions.