Accessibility Statement

This page documents accessibility commitments, supported assistive technology, features, and known gaps across brightraven.world and the products hosted here.

Last reviewed: 2026-04-20 · Covers brightraven.world (main site) and Maida v0.4.2.

Contents:

• Conformance target
• brightraven.world (main site)
• Maida (desktop application)
• Known limitations
• Report an issue

Conformance target

We aim for WCAG 2.2 Level AA as a baseline across all pages and products, with Success Criterion 2.3.3 (Animation from Interactions) Level AAA as an additional target because Maida uses animated transitions to communicate state.

We do not claim "fully accessible" status. WCAG does not have such a state. We claim that we actively test, document what we know works, and document what we know does not.

brightraven.world (main site)

The main site and the Maida landing page at /maida/ are static pages. Accessibility is covered by standard web practices:

• Semantic HTML (main, section, nav, h1) for landmark navigation
• All interactive elements reachable via Tab / Shift+Tab
• Decorative SVG marked aria-hidden="true"; icon-only links labeled with aria-label
• Color contrast meets WCAG AA in both light and dark themes; the Maida landing page ships its own theme toggle that respects user preference
• No keyboard traps, no forced autoplay, no content reflow shifts during interaction
• Skip-to-main-content link on pages that have fixed header navigation

Maida (desktop application)

Maida is a Tauri-based desktop app. Its accessibility surface is larger than the static site because the app handles gamepad input, screen reader announcements for state changes, and a handheld-first interaction model. Below is what the internal red-line guardrails translate to in user-visible behavior.

Keyboard navigation

• Every interactive control reachable via Tab / Shift+Tab in visual order
• Enter activates buttons; holding Enter for 3 seconds commits anchor actions (such as anchoring a kata or launching a game)
• Space on buttons is intentionally suppressed to prevent NVDA browse-mode synthetic clicks from bypassing long-press friction. This is a deliberate safety deviation from default browser behavior, not an oversight
• Focus order follows visual layout, top-to-bottom and left-to-right

Gamepad navigation

• D-pad and left stick drive focus between controls, mirroring keyboard arrow keys
• Right stick scrolls long pages (kata list, settings, legal pages) at 1500 px/sec at full deflection, proportional to stick position, with a dead zone of 0.15
• A button activates focused controls; B button navigates back
• LB / RB swap between Kamae (preparation) and Rin (presence) views
• Gamepad focus ring uses both :focus and :focus-visible pseudo-classes; Chromium does not always classify gamepad-driven programmatic focus as keyboard-sourced, so the pairing ensures the ring is always visible

Screen reader announcements

• Tested on NVDA (Windows). Other Windows screen readers should work but are not regularly validated per release
• State changes (TRY, NOT NOW, anchor, undo) announced via live regions rather than assumed-visual
• The frozen cooldown screen uses two separate live regions to avoid audio stutter: a visual countdown in Arabic digits (font-variant-numeric: tabular-nums) for sighted users, and a spelled-out-numbers announcement track for screen reader users
• Number spelling tables cover 0 through 30 across all four locales (English, Japanese, Traditional Chinese, Simplified Chinese)

Reduced motion

• The OS-level prefers-reduced-motion setting is honored throughout the app
• When reduced motion is active, the frozen cooldown screen replaces its per-second ticking countdown with a static "approximately X seconds" message
• There is no in-app toggle for motion preference. WCAG Success Criterion 2.3.3 (AAA) defers to the user-agent / OS setting; having two controls (OS and app) would create inconsistency

Friction as protection

Certain interactions use deliberate friction to protect against accidental destructive decisions:

• Launching a game requires a short TRY tap plus a 3-second hold to anchor the decision; a short tap alone surfaces the game for inspection without launching
• NOT NOW decisions can be undone exactly once per decision; this prevents infinite retries that would erode deliberate choice
• Friction thresholds (300ms tap, 3000ms anchor) are documented constants, not shortened for perceived UX speed

Known limitations

Honest disclosure of current gaps:

• macOS screen readers not tested. Maida does not ship macOS as of v0.4.2. If macOS support is added, VoiceOver testing will be added alongside it.
• Orca (Linux) has architectural limitations. Orca has been tested with Maida. It does not include a browse-mode equivalent to NVDA, so reading the entire page as a document is not available. This is an Orca design choice, not something Maida can work around. State announcements via live regions work in recent Orca versions. The interaction profile is different from NVDA but Maida is usable under Orca.
• JAWS and Narrator (Windows) not regularly tested. NVDA is the primary Windows screen reader target. Other screen readers are expected to work but are not validated per release.
• No in-app text-size or high-contrast toggles yet. The Windows OS-level text scaling setting is honored. Dedicated in-app accessibility preferences are planned for v0.5.x.
• Touch-only input is unsupported. Maida is designed for keyboard, gamepad, and mouse. Touch handhelds running desktop mode (Steam Deck, ROG Ally) should use keyboard or gamepad input.
• No skip-to-content landmark in the Maida app shell. Current navigation is short enough that the value is low, but the pattern will be added for parity with web conventions.
• Linux (WebKitGTK) gamepad quirks. On Linux, the WebKitGTK runtime that Tauri uses does not expose two browser features Maida relies on: (1) the GamepadHapticActuator API is absent, so the Haptic feedback setting silently has no effect; (2) right-stick analog scroll caps at roughly 75% of the maximum scroll position on long pages. Keyboard, mouse, and D-pad-based navigation are unaffected, and both are disclosed in the app's in-app accessibility notes. Tracked as issue #5 (haptic) and issue #3 (scroll cap).

Report an issue

If you find an accessibility barrier, please report it. Two channels:

• Open an issue on the Maida GitHub repository
• Email Bertram with "accessibility" in the subject line

We commit to acknowledging accessibility reports within 7 days and to including confirmed fixes in a patch release when feasible.