Decision 0017 chose published gpui 0.2.2 over a Zed git revision, accepted
that the crate has no AccessKit API at all, and said the mitigation was "a
narrow `a11y` adapter trait, introduced now while there are few call sites"
so that moving off 0.2.2 would be "a swap rather than a rewrite". No such
trait, module, or file was ever written. Decision 0023 records what that
cost: `apps/lumbridge/src` now builds 147 elements and gives 20 of them a
stable identity, and the only trace of the promise is a `describe()` in the
sidebar model that produces the screen-reader sentence, is tested, is called
by nothing, and carries an `#[allow(dead_code)]` naming a record it outlived.
`apps/lumbridge/src/a11y.rs` is that adapter, landed on 0.2.2 as stage 1 of
decision 0023 and before the dependency moves, so the dependency change is
paid for on its own. The trait carries the five operations
`spikes/gpui-accessibility-probe` proves compile at Zed `ce48461e` -- role,
label, description, selected state, and a stable accessibility identity --
implemented for `Div` and `Stateful<Div>`, which are the only two builders
the shell constructs.
Every body drops the value it is given and returns `self`. That is the
whole point: 0.2.2 has nothing to hand the value to, so the file is a
vocabulary and a set of call sites, not a feature. What it is not is a
blanket `#[allow]` -- the arguments are consumed by a `discard` helper so
`clippy::pedantic` passes on the code's merits, and the next real mistake
in this file is still caught.
Two choices exist only to keep stage 5 confined to this file. The methods
are prefixed `a11y_` because GPUI's own builders at the target revision are
named `role`, `aria_label`, `aria_description`, `aria_selected` and
`accessibility_id`, and a trait of ours carrying those names would make
every call site ambiguous the moment both are in scope -- which is the
rewrite the adapter exists to avoid. `Role` is Lumbridge's own enum rather
than an alias, because `gpui::Role` does not exist to alias and because the
enum should name what the product claims, not what today's dependency
happens to spell.
The derivations sit here too, and are the testable part: `PaneSemantics`
derives the four facts `UX_VERTICAL_SLICE.md`'s hard gate names -- which
pane, its selected state, its execution target, its waiting state -- from
strings the pane header already prints, so an assistive technology cannot
announce a machine the screen is not showing.
The gate is not met and this does not move it. No accessibility tree is
produced, nothing reaches AT-SPI or VoiceOver, and no test here is an
assistive-technology claim.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SPYebLiN2w4TqnHUYGdECq
