Site information
Accessibility
KAINYNE is committed to making its browser card games and website usable by everyone. This page explains our target standard, what we've built, where gaps remain, and how to tell us when something doesn't work for you.
Conformance target
We target WCAG 2.1 Level AA conformance across all pages and game surfaces. KAINYNE is a small project and our games are in active development — conformance is a goal we pursue incrementally, not a claim we make today.
What we've implemented
- Skip-to-content link as the first focusable element on every page.
- ARIA roles and labels on interactive elements (buttons, navigation, live regions for game-state updates).
prefers-reduced-motionmedia query — all CSS animations and transitions are disabled when the OS reduced-motion preference is set.- Keyboard-navigable navigation and game controls where turn-based logic allows it.
- Sufficient colour contrast — electric yellow
#e8f020on dark navy#0a0b0fexceeds the 4.5:1 AA ratio for normal text. - Semantic HTML throughout (
<main>,<nav>,<footer>, heading hierarchy). - All images and icon elements carry
alttext oraria-hidden="true"where decorative. - Mobile-responsive layouts down to 320 px viewport width.
Known gaps
- Some tap targets in game UIs are smaller than the recommended 44 × 44 px minimum.
- Several real-time game interactions (card slap, rapid-deal animations) are pointer-dependent and do not yet have keyboard equivalents.
- Screen-reader live-region announcements for game-state changes (opponent's move, card draws) are incomplete on some game surfaces.
- Focus styles in some game panels use only colour to indicate focus without a secondary indicator.
Reporting an issue
Found a barrier? We want to know. Use the in-site bug reporter or email contact@kainyne.com with a description of the page, the assistive technology and browser you're using, and what you expected to happen. We aim to respond within two business days.
Technical approach
We test against the WCAG 2.1 success criteria manually and with automated tooling (Lighthouse accessibility audits in CI). We use native HTML elements wherever possible — custom game components are built with explicit ARIA attributes rather than overriding native semantics.