Accessibility

What works today

Keyboard. Every control is reachable by keyboard. The spacebar spins the wheel from anywhere on the page except inside a text field. Result windows take focus when they open and close with Escape.

Screen readers. The wheel is a canvas, which a screen reader cannot describe, so the important information is provided as text alongside it: the entry count and current odds are in a live region under the wheel, and the result is announced in a labelled dialog. The written content on every page is ordinary HTML.

Reduced motion. If your system is set to reduce motion, the ambient background stops animating, confetti is suppressed, and the spin is shortened to a single fast turn rather than five. The result is identical either way.

Contrast and themes. Both light and dark themes are designed to meet WCAG AA contrast for body text. The theme follows the button in the header and is remembered on that device. Wheel labels are dark text on light slices in both themes.

Zoom and reflow. The layout reflows to 320px and supports zoom to 200% without horizontal scrolling. Wide content scrolls inside its own container rather than pushing the page sideways.

No motion traps. Nothing auto-plays, nothing flashes, and sound is off-by-default only in the sense that it never plays until you spin — it can be turned off entirely in the wheel options.

Known gaps

Listing these is more useful than claiming full compliance:

• The wheel is visual. A screen reader user gets the result as text, but not the experience of watching the wheel. For a blind user the spin animation is dead time; the result is what matters, and it is announced.
• Colour is used to distinguish slices. The labels carry the meaning, but the colour picker is inherently visual and there is no non-visual equivalent.
• No high-contrast theme beyond the standard light and dark ones.
• The fullscreen presentation mode has had less testing with assistive technology than the standard layout.

None of these are settled. If you hit a barrier, the specific detail is far more useful than a general report.

Report a problem

Email [email protected] with the page, your assistive technology and browser, and what happened.

Accessibility bugs are treated as bugs, not as feature requests.