rfc: accessible mode

Inizia con l’utility isAccessible() completata e i relativi test sull’ordine di risoluzione in @clack/core, poi leggi core/src/types.ts e il livello di rendering condiviso. Usa la checklist organizzata per fasi per delimitare un gruppo di prompt, risolvendo al contempo le domande aperte elencate con i maintainer. Il lavoro è completato quando i prompt rilevanti hanno un percorso di rendering accessibile isolato e la validazione copre il comportamento proposto.

coming out of the discord convo about spinners and screen readers. tldr of the problem: spinners and live-redrawn prompts get re-announced on every repaint by voiceover/nvda/orca, which makes clack prompts effectively unusable with assistive tech. github hit the same wall with their cli and shipped static text + numbered inputs instead: https://github.blog/engineering/user-experience/building-a-more-accessible-github-cli/

detecting screen readers isn't viable (the reader runs client-side, so over ssh/containers there's zero signal, and local platform APIs are inconsistent + amount to sniffing disability status). so the proposal is an explicit opt-in following the emerging ACCESSIBLE env var convention (charmbracelet/huh already honors it in go land). nothing in the js prompt ecosystem does this yet, so clack adopting it likely sets the convention.

this issue is the coordination doc: design + checklist live here, chatter can stay on discord.

activation semantics

accessible mode is enabled when any of these resolve true, in priority order:

1. explicit accessible: true option on a prompt (or global setting)
2. ACCESSIBLE env var set to any non-empty value (0 and false explicitly disable)
3. open question: should !isTTY imply it, or stay a separate degradation path?

behavior per prompt

implementation approach

intent is for accessible mode to be a distinct render path rather than if (accessible) conditionals scattered through every prompt. all prompts already flow through the shared render layer in core, so the accessible output should hang off that seam. keeping it isolated there also means future renderer work inherits it for free.

proposed plan

• isAccessible() util in @clack/core + resolution order tests
• thread accessible option through shared prompt options in core/src/types.ts
• baseline screen reader recording against current spinner + select (before/after material)
• pr 1: spinner, progress-bar, task/task-log/stream (static output path)
• pr 2: select, select-key, multi-select, group-multi-select, limit-options
• follow-up: autocomplete
• pr 3: cleanup pass on text/confirm/password/path/multi-line/date + note/box/log/messages
• validation session with a screen reader user on a build
• docs page + accessible example in examples dir

open questions

• !isTTY implies accessible mode, or keep as separate degradation?
• global setting api shape (per-prompt option only vs updateSettings-style global)
• interval default for spinner status lines (30s? 60s?)
• how custom renderers compose with accessible mode