feat(standard): add §18 accessibility as opt-in mode layer — v1.33

[UnbreakableMJ]

Why

Accessibility in the Standard was three lines in §13 — a chapter that opens by mandating Material Design "for all graphical applications." Meanwhile PROJECTS.md shows the estate is overwhelmingly Rust CLI/TUI (59 Rust / 13 CLI / 10 TUI mentions vs. 1 Flutter). The dominant application class had no accessibility coverage, no acceptance criteria, and no §16 audit gate.

What changed

§18 (new chapter) — Accessibility (Opt-In Mode Layer). Two-sided rule: mandatory for developers to implement, off by default for users. The Steelbore theme is untouched and remains the sole default.

• §18.1 Activation — one toggle, four sources with defined precedence: --accessible > SPACECRAFT_A11Y > config > auto-detect hints (TERM=dumb, NO_COLOR, GTK_MODULES=…gail:atk). Unset everywhere ⇒ standard Steelbore rendering, unchanged. Explicit 0 always wins.
• §18.2 CLI & TUI — split into rules that apply always (status never color-only: [OK]/[ERROR]/[WARN]/[INFO]; stdout/stderr separation) and rules gated behind the toggle (no animation, no decorative art, linear output, tabular fallback, legible prompts). Plus §18.2.3 TUI linear mode: a non-redraw append-only stream mode, and an equivalent non-interactive CLI path where a TUI would otherwise be the only route.
• §18.3 GUI — AccessKit required for Rust/custom-drawn UI (one API over UIA / NSAccessibility / AT-SPI); GtkAccessible, Flutter Semantics, QAccessible for toolkit-native paths. Explicit name + role on every interactive element.
• §18.4 Verification & remediation — verification by real screen reader (Orca/NVDA/VoiceOver) and espeak-ng for CLI output, not by inspection.
• §18.5 Games carve-out — see below.

§18.5 — games are exempt from §18 and §10 in full. §18 assumes a character grid or a widget tree with roles and names; games are real-time simulations rendering custom non-widget interfaces, and the techniques that suit them (remappable controls, colorblind-safe signalling, subtitles, difficulty options) are a different discipline. Accessibility in a game is optional, nothing is enforced, and its absence is never a compliance failure.

• §18.5.1 — declaration + registry, mirroring the §5.3 general-use carve-out: a README declaration plus a registry table, today naming Ironway. "Is this a game?" gets a documented answer rather than an arguable one.
• §18.5.2 — a recommended list a game may decline outright (remappable controls; leave Insert/CapsLock/KP_Insert/Ctrl+Option alone; colorblind-safe signalling; subtitles; reduced motion).
• §18.5.3 — shared vocabulary: a toggle a game chooses to ship should use the §18.1 names. Constrains naming only; requires no feature to exist.

§11.1.1 (new) — accessibility theme variants. Additive siblings, never replacements:

Variant	Behavior
steelbore	Default, canonical §11 palette, unchanged
steelbore-high-contrast	Every token ≥7:1 (AAA) on Void Navy
steelbore-mono	4-bit ANSI, defers to the user's terminal palette

High-contrast lifts only the two tokens that need it — accent #4B7EB0→#7FAEDC (4.77:1 → 8.73:1) and error #FF5C5C→#FF8080 (6.74:1 → 8.41:1). The other four are §11 values verbatim, and Void Navy remains the background in every variant.

§11 — contrast guarantee scoped honestly. The AA claim covers foreground-on-Void-Navy only (measured: Amber 7.64:1, Steel Blue 4.77:1, Radium Green 14.87:1, Red Oxide 6.74:1, Coolant 14.74:1 — all pass). But 9 of 10 inter-token pairs fall below 3:1 — Molten Amber on Red Oxide is 1.13:1, Radium Green on Liquid Coolant is 1.01:1. Text on a palette-colored fill now requires its own pair verification.

§10 — keybindings. Bindings must be user-remappable; NVDA/Orca/VoiceOver modifier chords must not be captured. Does not apply to registered games (§18.5), including the pre-existing CUA and Vim rows — modal editing and text-editor chords are a poor fit for real-time play.

§13 — target raised. WCAG 2.1 AA → WCAG 2.2 AA, plus EN 301 549 clause 11 (non-web software) as the anchor for CLI/TUI — the only normative text that addresses terminal software. EN 301 549 V4.1.1 (expected 2026) incorporates WCAG 2.2; the EAA has been enforceable since 2025-06-28.

§16 — new §18 gate; §10 and §13 gates extended; §10 and §18 gates marked N/A for registered games.

Note on scope

§18 applies to every non-game project immediately, so projects predating v1.33 are non-compliant until retrofitted. Rather than soften this to a recommendation, §18.4 requires each to carry a dated remediation entry in PROJECTS.md until it conforms. Registered games are excluded — they owe no remediation entry, because they owe no conformance. Those retrofits are follow-on work.

Verification

• makeinfo --no-split The_Steelbore_Standard.texi → zero errors, zero warnings
• @settitle / @set VERSION read 1.33; @set UPDATED reads 2026-07-24
• Exactly one v1.33 changelog entry — the carve-out extends it rather than duplicating it
• texi2any --html renders §18.5 and its registry table; Void Navy intact
• reuse lint on a tracked-files-only checkout → compliant (7/7)
• .github/validate-configs.py → 0 failed
• Contrast ratios recomputed for every variant value

Follow-up PRs sync spacecraft-standard-constitution + spacecraft-theme-factory and add the spacecraft-accessibility skill.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.