Accessibility Statement
Last updated: July 12, 2026
Draft for review — this document is a template and requires review by qualified legal counsel before launch.
Atomance LTD wants ADYTUS to be usable by as many people as possible, including people who rely on assistive technology. Arguing a case well has nothing to do with how you see, hear, or move — the interface shouldn’t either.
1. Our standard
We target the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA as our design and engineering standard, and we treat accessibility as part of building a feature, not a retrofit. A formal conformance audit has not yet been completed — this statement will be updated with its results. [AUDIT DATE / RESULT — TBD]
2. What is built in today
- Keyboard operability. Interactive controls — navigation, forms, dialogs, tabs, menus, toggles — are built on accessible primitives (Radix UI) with correct roles, focus management, and visible focus rings. Dialogs trap and return focus; menus follow the expected arrow-key patterns.
- Semantic structure. Pages use real headings, lists, tables, and landmarks so screen readers can navigate by structure rather than by guesswork.
- Labels and names. Icon-only controls (such as the watchlist star or notification dots) carry text alternatives via ARIA labels; form fields have programmatic labels.
- Colour and contrast. Light and dark themes are both first-class, your choice is remembered, and status information (live, settled, agree/disagree) is conveyed with text alongside colour — never colour alone.
- Resizable text and reflow. Layouts are responsive and built with relative units, so browser zoom and larger text sizes reflow rather than clip.
- Status updates. Important state changes (pauses, errors, confirmations) are announced through appropriate roles/attributes rather than visual position alone.
3. Known limitations — honestly stated
- The live show.A contest’s scoring phase is a fast-moving, real-time visual experience (the Oracle orb, tick-by-tick swings). We surface the underlying state in text (lean, countdowns, per-round reasons), but the pace and density remain challenging through a screen reader. Improving the non-visual show experience is on the roadmap. [SCREEN-READER SHOW SUMMARY — PLANNED]
- Live chat during busy rounds can produce rapid message streams; rate and verbosity controls for assistive tech are planned.
- Motion.Some celebratory and ambient animations do not yet fully respect the “reduce motion” system preference. [PREFERS-REDUCED-MOTION PASS — PLANNED]
- Third-party steps. Payment checkout and identity verification are provided by external specialists; their screens are outside our direct control. We pass accessibility feedback about them upstream.
4. Compatibility
The Service is built for current versions of major browsers (Chrome, Safari, Firefox, Edge) on desktop and mobile, and is intended to work with platform screen readers (VoiceOver, NVDA, JAWS, TalkBack) and platform zoom/contrast settings. If a combination you rely on misbehaves, that is a bug — please tell us.
5. Alternatives while something is broken
If a barrier blocks you from something that matters — entering a contest, reading a result, claiming a prize, setting a responsible-play limit — email us and we will complete the action with you by email while we fix the underlying issue. An accessibility barrier will never cost you a prize you won.
6. Tell us about a barrier
Email support@adytus.com with the page, what you were trying to do, and the assistive technology involved. We aim to acknowledge accessibility reports within [N BUSINESS DAYS — TBD] and to prioritise fixes that block core actions. This statement is reviewed and updated as the product changes.