Release v0.7.0

Added

• A small, versioned, closed-schema display-preferences module (text size, contrast, spacing, control size, motion) that applies deterministically before first paint, degrades safely on corrupt/future schema or denied storage, and stays in sync across same-origin tabs. (#20)
• A display-preferences menu (gear trigger + dialog) on all three onboarding journeys, reachable from the shared onboarding frame. (#20)
• ARIA tab/tabpanel semantics, step-transition focus, and a live-region step announcement on every onboarding CommandStepper, retrofitted at the app level since CommandStepper renders none of this and only reports step changes for header clicks - not Next/Previous (filed upstream as Cratis/Components#249). (#20)
• An error summary that takes keyboard focus the moment it appears, so a screen-reader user lands on it instead of finding it later by tabbing through the page. (#20)
• Semantic autocomplete on the name/organization fields, and a real <main> landmark with an <h1> heading on every onboarding frame. (#20)

Changed

• Onboarding's waiting/progress states now expose a role="status"/aria-live="polite" announcement (reusing ProgressSpinner's own accessible label where a spinner is present). (#20)
• Keyboard focus now gets a reinforced, forced-colors-aware :focus-visible outline across this app's own elements (@cratis/components already does this for its own controls). (#20)
• This app's own CSS now honors prefers-reduced-motion, in addition to the explicit in-app motion preference. (#20)
• color-scheme relaxed from a hard dark to dark light, and <html> now declares lang="en", so native controls can still follow the operating system rather than the app overriding it outright. (#20)

Summary

Delivers the early, protocol-independent portion of WP-09: keyboard/focus/ARIA foundations and the neutral preference module, across all three onboarding journeys (organization setup, invitation acceptance, self-service registration), which share OrganizationSetupFrame/UserSetupFrame.

Two framework-level accessibility gaps were filed upstream while implementing this, with app-level workarounds left in place until they land:

• Cratis/Components#249 - CommandStepper renders no ARIA tab/tabpanel roles/relationships, and only reports step changes for header clicks, never Next/Previous (the path a linear wizard actually uses).
• Cratis/Arc#2661 - CommandForm's auto-rendered field label has no htmlFor, so clicking the visible label text does not focus the field (the input still gets an accessible name via a separate aria-label fallback).

Deferred, not part of this PR:

• Manual/browser accessibility evidence (screen reader pass, high-zoom and narrow/short-viewport checks, forced-colors visual QA) - the issue itself is explicit that computed CSS/SSR output alone must not be claimed as compliance; this PR delivers the underlying behavior and defers the recorded manual verification pass.
• Dialog focus return on close is already handled by @cratis/components' Dialog (built on react-aria-components' Modal/ModalOverlay) - verified by inspection, not re-implemented here.
• Independent of trust and compatibility decisions (#11), per the issue's own sequencing note - nothing here depends on it.

Test plan

• yarn lint:ci - 0 errors
• npx tsc -b (yarn compile) - 0 errors
• yarn test - 109/109 passing, including new specs for the preference schema/storage/effective-preference/reset logic and the stepper ARIA/focus-index/announcement helpers
• yarn build - succeeds
• No .cs files touched - no backend build required
• Manual accessibility evidence (screen reader, high zoom, narrow viewport, forced colors) - deferred, see above

🤖 Generated with Claude Code

https://claude.ai/code/session_014jfWkrU6BPcC8T3gFNAc8z