Expose Terminal Accessibility Tree for macOS Assistive Apps

[derricksiawor]

Pre-submit Checks

• I have searched Warp feature requests and there are no duplicates
• I have searched Warp docs and my feature is not there

Describe the solution you'd like?

Requested Accessibility Surface

Below is the minimal AX surface that would fully unblock compatibility.

1. Window Enumeration

Windows should appear under:

AXUIElementCreateApplication(pid)
→ kAXWindowsAttribute

Each window should expose:

Stable kAXTitleAttribute

Standard NSWindow accessibility behavior

This largely appears to work today.

2. Tab Enumeration
   Tabs should be discoverable inside each window through either:

Option A — Standard Tab Group

AXTabGroup
└── kAXTabsAttribute

Returning tab elements.

Option B — Radio/Button Style Tabs

Expose tab children as:

AXRadioButton

AXTab

With:

kAXTitleAttribute → tab display title

kAXValueAttribute → selected state (1 / 0)

This matches what Terminal.app and iTerm2 already expose.

3. Per-Tab Visible Buffer Text

Each tab/window should expose an:

AXTextArea

(or equivalent text-role accessibility element)

whose:

kAXValueAttribute

returns the currently visible terminal buffer as plain text.

Minimum Requirement

Visible viewport buffer

Nice-to-Have

Scrollback buffer access

The visible buffer alone is sufficient to fully support Echo.

4. Accessibility Notifications

The following AX notifications would enable efficient real-time updates:

kAXFocusedWindowChangedNotification

kAXValueChangedNotification on the text area

kAXUIElementDestroyedNotification

These are important for:

tab lifecycle tracking

window lifecycle tracking

incremental buffer updates

active-session detection

5. Selected Tab Signal

The active tab should be identifiable via either:

kAXValueAttribute == 1 on the selected tab element

kAXFocusedAttribute

equivalent focused-state signaling

Polling is acceptable if notifications are unavailable.

Is your feature request related to a problem? Please describe.

Echo is a macOS companion app that observes terminal activity across multiple terminal emulators (Terminal.app, iTerm2, etc.) to power voice and agent workflows.

Our detection layer is intentionally adapter-free and universal:

We walk each terminal application's Accessibility (AX) tree via:

AXUIElementCreateApplication(pid)

kAXWindowsAttribute

We enumerate tabs under:

AXTabGroup

kAXTabsAttribute

AXRadioButton children

We read the visible terminal buffer through:

kAXValueAttribute on the AXTextArea child

This architecture currently works across every major macOS terminal except Warp.

Warp appears to render its UI through a custom GPU surface that exposes little to no meaningful Accessibility tree information:

No AXTabGroup

No AXRadioButton / AXTab hierarchy

No AXTextArea

No accessible visible buffer text

As a result, Warp becomes a special-case / tier-2 terminal in our compatibility matrix, which is the opposite of what we want — Warp users are exactly the developer cohort we'd most like to support first-class.

Additional context

This would not only unblock Echo, but also improve interoperability with the broader macOS accessibility ecosystem:

VoiceOver

screen readers

dictation tools

accessibility automation

terminal-aware AI agents

developer productivity tooling

Terminal.app and iTerm2 already expose this AX structure successfully, so the precedent on macOS is well-established.

Even a minimal opt-in setting such as:

Settings → Privacy → Expose accessibility tree to assistive apps

would immediately unlock support for a large category of accessibility and automation tooling.

Operating system (OS)

macOS

How important is this feature to you?

5 (Can't work without it!)

Warp Internal (ignore) - linear-label:39cc6478-1249-4ee7-950b-c428edfeecd1

None

[oz-for-oss]

@derricksiawor

Here's what I found while triaging this issue:

Current code appears to expose a single focused host-view accessibility value for screen-reader announcements, but not a discoverable per-tab AX tree or per-tab visible terminal text area. This looks like a real feature gap rather than a configuration issue.

Maintainer details

I concluded that macOS accessibility enhancement request to expose Warp windows, tabs, selected tab state, and visible terminal buffer text through a structured native AX tree for assistive apps..

Triage

This is a clear macOS accessibility enhancement request: expose Warp's window/tab/session structure and visible terminal buffer text through native AX APIs so assistive apps can enumerate tabs, identify the selected tab, and read the active terminal text.

Reproducibility: High. The behavior is a product/API surface gap rather than an intermittent runtime bug, and the current code matches the reported limitation.

Likely implementation area: WarpUI/macOS accessibility bridge plus workspace tab and terminal view plumbing. The current macOS bridge exposes accessibility content primarily as focused-view values/announcements through the native host view/window. TerminalView::accessibility_data synthesizes terminal content for the focused view, but there is no evidence of a native AX tab hierarchy (AXTabGroup, AXTab, AXRadioButton) or per-tab AXTextArea children that external apps can walk.

Duplicate check: I scanned open issues for AX/accessibility-tree/assistive-app/visible-buffer terminology. Existing accessibility issues such as #11125, #8979, #7201, and #3847 cover broader screen reader or platform accessibility problems, but they do not match this specific macOS AX tab/buffer API request closely enough to mark this as a duplicate under the repository dedupe rules.

No reporter follow-up is needed for initial triage; the requested minimum AX surface and acceptance criteria are already detailed enough for product/technical discovery.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz