# YSD-16065 — Which assistive technology the workspace commits to supporting

- **Status:** proposed
- **Priority:** EXT — blocking for §16 acceptance (seven of the eight critical
  journeys cannot be shown completable until this is answered, and no
  recruitment changes that)
- **Decision owner:** @GreyChimp
- **Drafted:** 2026-08-16 by Claude Code (Opus 5)
- **Approval:** pending

## Question

`supported-baselines.md` names exactly one assistive technology: VoiceOver on
macOS, at secondary tier. Every other modality is, by that document's own rule,
UNSUPPORTED-UNTESTED — "it may work, but no gate protects it, and support claims
for it are forbidden until it joins this file with a matrix entry."

Measured on 2026-08-16 against the shipped journeys and the shipped capability
table, that one row is doing more work than one row can do:

| Journey                    | Modalities its steps demand that the matrix does not declare   |
| -------------------------- | -------------------------------------------------------------- |
| study-an-authorized-source | speech-input, switch-access                                    |
| observe-at-a-chosen-moment | braille-display, screen-magnifier, speech-input, switch-access |
| compare-with-uncertainty   | braille-display, screen-magnifier, speech-input, switch-access |
| pin-into-a-collection      | braille-display, speech-input, switch-access                   |
| connect-and-traverse       | braille-display, screen-magnifier                              |
| finding-to-practice        | screen-magnifier                                               |
| study-without-models       | speech-input, switch-access                                    |
| notebook-to-report         | — (screen-reader only; genuinely awaiting a participant)       |

And the capability table `STUDY_ACCESSIBILITY_CAPABILITIES` — which says of
itself that "every entry is grounded in a shipped Studio behavior; none is
aspirational" — declares four requirements `supported` whose driving technology
the matrix does not name: `keyboard-navigation` (switch-access, speech-input),
`focus-visible` (switch-access), `text-resize` (screen-magnifier), and
`screen-reader-labels`, which has a declared technology nobody has driven.

So two shipped artifacts assert opposite things about the same four modalities.
The matrix says silence means refusal; the capability table says the
requirements those modalities rest on are supported. **This is not a recruitment
question and recruiting cannot answer it**: seven journeys report
`undeclared-modality`, and that verdict is checked before any session because it
is true before anybody is hired. The gap is in the claim.

The question is therefore: which assistive technologies does this workspace
commit to supporting, at what tier, and what does it say about the ones it does
not?

## Recommendation

Declare **screen-magnifier and speech-input** as the next two modalities, at
secondary tier, and declare **switch-access and braille-display** explicitly as
UNSUPPORTED-UNTESTED with the reason written down rather than leaving them
unstated. A row enters the matrix only when a task-completion session has
actually been driven with it — the matrix records support, not intent.

The ranking is not a preference. Screen magnification and speech input ship
inside the operating systems already declared primary and secondary (macOS Zoom
and Voice Control; Windows Magnifier and Voice Access), so a session needs a
tester and no procurement; between them they reach six of the seven blocked
journeys and three of the four unobserved claims. Switch access needs a switch
device and braille output needs a display, and a declared row nobody can drive
is the failure this decision exists to stop.

Naming the refusals matters as much as naming the support. The matrix's silence
is currently being read two ways at once, and an explicit "not supported,
because no gate can be run without hardware nobody has" is a sentence a person
who depends on a switch can act on. Silence is not.

## Options considered

- **Declare all four modalities now.** Rejected: it is the exact claim the
  matrix forbids — support asserted before anything could be run against it —
  and it would turn seven honest `undeclared-modality` verdicts into seven
  `unevaluated` ones without changing a single fact about the product.
- **Narrow the capability table instead.** Rejected, though it is the tempting
  symmetrical move: downgrading `keyboard-navigation`, `focus-visible` and
  `text-resize` would state that the product is not keyboard-operable and its
  text does not resize, which is false — the Playwright keyboard journey and the
  200% reflow assertion both pass. Lowering a true claim to resolve a
  contradiction hides the contradiction rather than settling it.
- **Re-word the journeys so their steps stop demanding what nobody supports.**
  Rejected as the worst of the three: the demands are properties of the work —
  selecting a region on a frame IS a pointer-precision task — and editing the
  demand to fit the matrix makes the evaluation agree with the claim by
  construction.
- **Two OS-resident modalities at secondary tier, hardware-dependent ones
  refused in writing** — recommended.

## Consequences

- §16 acceptance stays open until sessions exist, and it stays open for a reason
  that is now written down against a named owner rather than filed under
  "recruit participants".
- Two modalities acquire a real obligation: a tester, a session, and a row in
  `DECLARED_ASSISTIVE_TECHNOLOGIES` that must agree with the published matrix.
- Two modalities acquire a published refusal. A person using a switch or a
  braille display is told, rather than left to discover it.
- `screen-reader-labels` stays declared and unobserved until somebody completes
  a journey with VoiceOver; that is participant work and this decision does not
  change it.

## Machine-enforced outcome

On approval, `DECLARED_ASSISTIVE_TECHNOLOGIES` gains the approved rows and no
others, the published matrix and that constant are asserted to agree, and a
modality declared UNSUPPORTED-UNTESTED may not appear in the roster. The release
gate continues to name every shipped support claim no session has driven, so an
approved row does not become evidence by being written down.

## Pending control

The release gate refuses to pass on a support claim nobody has driven.
`check-accessibility-evidence.ts --require-complete` fails when
`unobservedSupportClaims` is non-empty, naming each requirement whose declared
support rests on assistive technology no completed session has used — a branch
added on 2026-08-16, because until then the four claims were computed, printed
with a "!" and read by nothing that could fail. Beside it,
`atTaskCompletionReport` answers `undeclared-modality` for a journey whose steps
demand a modality the matrix does not declare, and that verdict is reached
before any session is considered, so no amount of evaluation can quietly
discharge a claim this decision has not yet made.