[Eyalm321]

The terminal grid is drawn to a texture, so assistive tech — screen readers, and
assistive automation like a desktop agent — sees each pane as an empty rectangle.
This hands it the visible screen as accessible text.

• accessibility feature, Linux only. It is dropped workspace-wide because
  accesskit pins windows 0.58 against wgpu-hal 29's 0.62; that conflict only
  exists when building for Windows, so the feature is requested from
  [target.'cfg(target_os = "linux")'.dependencies] and Windows resolution is
  untouched.
• PaneItem.a11y-text carries the text; TerminalPane exposes it through
  accessible-role / -label / -value, read-only.
• paneview fills it from the existing TerminalPane::screen_text(), behind
  a11y_wanted() — HYPERPANES_A11Y=1 forces on, NO_AT_BRIDGE=1 forces off,
  otherwise the GNOME toolkit-accessibility setting. Nothing is extracted when
  no assistive client is connected.

cargo check passes in rs/crates/app. Verified in a scratch worktree at this
commit alone, so it does not depend on anything else in flight.

🤖 Generated with Claude Code

[Eyalm321]

Superseded by main — closing rather than merging.

Everything this PR adds already landed on main in 11574d3 ("per-pane dictation (push-to-talk) and AT-SPI text for the terminal grid"), which shipped in v0.0.29. A line-by-line check against current main:

file	PR adds	already on main
rs/crates/app/Cargo.toml	7	7
rs/crates/terminal-widget/Cargo.toml	7	7
rs/crates/terminal-widget/ui/widget.slint	8	8
rs/crates/app/ui/types.slint	3	3
rs/crates/app/ui/paneview.slint	2	2
rs/crates/app/src/paneview.rs	27	24

The 3 paneview.rs lines that don't match exactly are older versions of lines main has since updated: a rustfmt-reflowed .args(...), and the a11y_wanted() doc comment, which main expands with the toolkit-accessibility / GTK_A11Y / bus-name detail. So the conflict is the same lines changed twice, not new work.

Branch head was ffab16c if it's ever needed.