Accessibility

PEAK3 Arena should be playable without a mouse and without animation. That is treated as a build requirement rather than a nice-to-have: the behaviours below are implemented in shared code and exercised by an automated test suite, so a redesign that loses them fails the build rather than shipping quietly.

We do not claim conformance to a specific WCAG level, and no independent audit has been carried out. Saying otherwise would be a guess.

• Skip link. A “skip to content” link is the first focusable element on every page and jumps to the #main-content landmark.
• Keyboard-navigable game boards. Game boards are operable from the keyboard — every interactive cell and control is reachable and activatable without a pointer.
• Dialog behaviour. Modal dialogs trap focus, close on Escape, lock background scrolling, and restore focus to the control that opened them. This lives in one shared module (lib/a11y.ts) so every dialog inherits it.
• Reduced motion. The prefers-reduced-motion setting is respected in both CSS and component code; animated reveals and counters fall back to their end state.
• Live status regions. Score changes, turn results and other asynchronous updates are announced through aria-live regions rather than only visually.
• Semantic landmarks. Navigation, main content and footer are real landmarks with accessible names, so screen-reader users can jump between them.
• Automated testing. An axe-based accessibility suite runs against real pages in a browser (src/tests/e2e/accessibility.spec.ts) as part of the test run.

Automated checks catch a minority of real accessibility problems, so this list is certainly incomplete. What we know about today:

• Daily Grid board navigation. The grid is reachable in Tab order only. It does not implement arrow-key movement with a roving tabindex, which is what a grid of that shape should offer, so crossing the board takes more keystrokes than it should.
• No independent accessibility audit and no assistive-technology test matrix has been carried out yet.

If something is unusable for you, that is a bug and we want the report. Tell us what you were trying to do, what happened, the page you were on, and the browser and assistive technology you were using, through the contact page. Accessibility reports are treated as defects, not feature requests.