RFC-005 — Accessibility: ARIA on canvas screens, reduced-motion contract

Status · Decided TA anchor · §constraints · §components Closed by · ADR-025 (2026-04-29) Why this is an RFC · Canvas and WebGL are inherently inaccessible to screen readers. The approach — what gets ARIA roles, what gets keyboard nav, where reduced-motion applies, what's explicitly deferred — is open with real cost/completeness trade-offs.

The question

Four of six screens render primarily to canvas or WebGL. Screen readers cannot read canvas content. What level of accessibility is achievable without rewriting the rendering architecture, and where does v1 draw the line?

Use cases

• Keyboard user navigating the mission library card grid
• Screen reader user accessing mission information via detail panels
• User with prefers-reduced-motion on solar system explorer or fly screen
• Keyboard user navigating between screens via the nav bar

Goals

• Nav bar fully keyboard-navigable with visible focus indicators
• Detail panel HTML content is screen-reader accessible
• Mission library keyboard-navigable
• prefers-reduced-motion stops/slows Three.js animations and canvas loops
• Documented honestly: canvas rendering is not accessible in v1

Constraints

Canvas and WebGL are opaque to screen readers. Full accessibility would require a parallel DOM structure mirroring canvas state — out of scope for v1.

Proposed approach

Tier 1 — v1:

• Nav bar: role="navigation", aria-label="Main navigation", focus rings visible
• Detail panels: semantic headings, role="complementary", focus management on open/close
• Mission library: cards as <button> elements with accessible text, arrow-key navigation
• prefers-reduced-motion: matchMedia detection, stops auto-orbit in 3D, reduces simSpeed in 2D

const reducedMotion = window.matchMedia('(prefers-reduced-motion: reduce)').matches;
// In animate: if reducedMotion, skip auto-orbit, halve simSpeed multiplier

Tier 2 — deferred to v2:

• Canvas object keyboard navigation (select a planet by keyboard)
• Full screen reader description of canvas content
• High-contrast mode

Alternatives considered

Full WCAG 2.1 AA on canvas — requires parallel accessible DOM; multiplies development cost; architecturally complex. Not feasible for v1.

No accessibility in v1 — the nav bar and mission library are HTML-based; these are low-cost wins with real user impact. Skipping entirely is not justified.

Third-party a11y library — adds a dependency; scope is narrow enough to implement without one.

Trade-offs

Tier 1 covers HTML-based parts (nav, panels, library) and the reduced-motion contract. Canvas and WebGL screens remain inaccessible to screen readers. This is documented honestly in the README.

Open questions

1. Should canvas screens have an aria-label describing what they contain ("Interactive 3D solar system. Use the detail panels for screen reader access.")?
2. Is prefers-reduced-motion sufficient for Three.js, or do screens need their own reduced-motion flags?
3. What's the minimum focus-ring visibility requirement on the dark-themed UI?

Closing evidence

Nav bar keyboard-navigable, detail panels screen-reader accessible, mission library keyboard-navigable, prefers-reduced-motion stops auto-orbit and canvas animations. All six screens. Available at Slice 6 gate.

How this closes

One ADR: the accessibility contract for v1 — what is covered, what is explicitly deferred, reduced-motion implementation pattern.