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:

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.