accessibility
Built to be readable, operable, and calm.
The roadmap calls for WCAG 2.2 AA and EN 301 549 discipline across the public site and Onyx. This page is the public conformance ledger: what is already designed into the surface, what is being checked, and what still needs a formal audit.
The public website is static HTML with a skip link, semantic headings, labelled navigation, visible focus states, and live status regions for changing network health. The Onyx app carries the same direction into the client: keyboard-first command search, status regions for connection state, and route-level metadata for direct links.
- Keyboard path
- Navigation, forms, public status, and Onyx command surfaces are reachable without pointer input.
- Motion limits
- Animated client scenes and public-site motion respect reduced-motion media preferences.
- Contrast controls
- Onyx exposes a user high-contrast switch and follows OS contrast preferences with stronger text, borders, focus outlines, and panel separation.
- Transparency controls
- Reduced-transparency users get solid app panels and chrome without changing the underlying theme.
- Readable state
- Status and stats pages expose text labels next to visual signals, not color alone.
- Static fallback
- Guides, community rules, status copy, and this ledger remain usable without client-side routing.
Washi roadmap work focuses on turning accessibility from a theme-by-theme manual fix into a predictable system: contrast, transparency, and motion controls should derive from the same design tokens as the rest of Onyx.
| Surface | Current state | Next check |
|---|---|---|
| Scene motion | Onyx exposes Animated, Still, and Off modes; Still renders a static frame and Off skips the background renderer. | Verify every route and canvas preset. |
| Room identity | Active rooms may use deterministic accent tokens, but the tokens are bounded OKLCH values rather than arbitrary community CSS. | Check room chrome across themes, high contrast, and forced colors. |
| Appearance access | Mobile users can open theme and background controls from Preferences without crowding the bottom navigation. | Verify the Preferences-to-Appearance handoff with keyboard and touch. |
| Reduced transparency | Explicit Onyx preference plus OS media-query support for solid surfaces. | Check all overlays against the mobile shell. |
| High contrast | Explicit Onyx preference plus prefers-contrast: more support. | Publish route-by-route AA scan results. |
| Forced colors | Client access ledger includes Windows forced-colors passthrough. | Run assistive-tech pass on dense panels. |
| Focus order | Static pages follow document order and visible focus; mobile app drawers trap and restore focus. | Audit remaining dense app panels and modal traps. |
| Live updates | Status feeds use text labels and live regions. | Throttle announcements in high-update views. |
Onyx also keeps appearance controls separate from functional access: themes are free, motion can be reduced, and important controls are not gated behind account status.
This is not a final VPAT. It is the public checklist that keeps the roadmap honest while the app moves toward WCAG 2.2 AA and EN 301 549 coverage.
- Public site pass: home, guides, community, status, stats handoff, and this page.
- Onyx app pass: connect, chat shell, composer, channel settings, voice controls, appearance, Preferences, Home, channel directory, message search, member list, and time scrubber.
- Assistive-tech pass: screen reader navigation, keyboard-only flows, forced-colors, and high-contrast modes.
- Conformance publication: summarize known support, exceptions, and remediation dates here.