Accessibility

This page does not claim conformance with WCAG at any level, because that claim would not be true, and a false accessibility statement is its own kind of barrier — it tells a person who is about to hit a wall that no wall exists.

Here is the honest version instead: what Ganbate does well, what it does badly, what is outright broken, and how to tell me when you hit something. I write this the same way I write the provably fair page — you should be able to check my claims rather than trust them.

Where things actually stand

Ganbate has never been through a formal accessibility audit: no expert review, no screen-reader test pass, no WCAG conformance assessment. There is no report to point you at, because none was ever produced. The whole of Ganbate's accessibility testing is the one automated check described below, and it covers four pages. I am one person, and the rest of that work has not happened yet. So I make no conformance claim at any level.

What I can tell you is what is in the code, because I read it before writing this page.

What works today

Reduced motion is genuinely respected. If your operating system is set to reduce motion, Ganbate honours it — not just in the stylesheets, but in the JavaScript that drives the animations. Card deals, dice reveals, count-ups and multiplier climbs resolve straight to their end state instead of animating. The reveal delay that holds a bet's outcome behind its animation drops to zero, so the result and the balance change land immediately rather than after a choreographed pause. The check fails safe: if the browser cannot report your motion preference at all, Ganbate assumes you want less motion, not more. What it is not is structural — see the next section.

Focus is always visible. There is a global focus ring applied to every button, link, input, select, textarea and custom focusable element in the app. Tab through Ganbate and you will be able to see where you are. It is an app-wide rule, not something sprinkled onto a few pages.

The controls are real controls. Game buttons — tiles in Mines, numbers in Keno, the bet and in-round collect actions — are actual buttons, not styled <div>s with click handlers bolted on. They are reachable with Tab, activated with Enter or Space, and the ones whose meaning is not obvious from their text carry a label (Mines tiles announce as "Tile 7", and selected tiles report their pressed state).

Page changes are announced. Ganbate is a single-page app, which normally means a screen reader says nothing at all when you navigate. Two visually hidden live regions are mounted app-wide — one polite, one assertive — and route changes are announced through them, so moving between pages is not silent.

Dialogs identify themselves and hold focus. Modals are marked as dialogs, flagged as modal, labelled by their title, and close on Escape. Focus moves into the dialog when it opens, Tab and Shift+Tab cycle within it, and focus returns to where you were when it closes. The limits of that are in the next section.

Most of the decorative graphics are hidden from screen readers. Plinko's board and the Wheel's disc are drawn with a graphics engine (pixi.js), and both of those canvases are marked aria-hidden. They are decoration: the outcome itself is rendered as ordinary HTML — Plinko's payout bins, the Wheel's segment legend and payout — so a screen reader is not left reading an empty canvas. That is the right shape. Whether the HTML underneath is good enough to follow a round is a separate question, and the answer is below — as is the one canvas that does not follow this rule.

There is an automated accessibility check in CI. Ganbate runs axe — a standard accessibility testing engine — against the app, checking it against the WCAG 2.0 A/AA and 2.1 A/AA rulesets, and failing the build on any critical finding. The check is real. Its limits are just as real, and I spell them out below rather than letting the phrase "automated accessibility testing" do misleading work in a sentence.

What is broken, weak, or missing

I would rather you read this list from me than discover it yourself.

The skip link was broken, and is fixed. Ganbate renders a "Skip to main content" link — the standard first-Tab affordance that lets a keyboard user jump past the navigation. For months it did nothing: it pointed at an element ID (main-content) that no element in the app actually had, so activating it silently failed, and its unit test passed only because the test created the missing target itself. I found this while writing this page, which is a fair illustration of why writing it was worth doing. It now points at a target that exists, and a test on the layout — not on the link — asserts the target is really rendered, so the two halves cannot silently drift apart again. This paragraph stays because the admission was published, and corrections belong next to the thing they correct.

Focus trapping has real gaps. Focus is moved into a dialog and cycled inside it, but the page behind an open dialog is not made inert — it is not hidden from assistive technology, so a screen reader in browse mode can still read the content underneath, and if focus escapes the dialog by some other route (a click behind it, a trip through the browser chrome) nothing pulls it back.

The automated check is narrower than it sounds — in three ways. It audits exactly four pages: login, register, dashboard, and settings. Not one of the sixteen games in the lobby, nor the lobby itself, the poker tables, chat, or the cashier. The part of Ganbate you actually spend your time in is the part the robot never looks at. It only fails on critical violations — serious ones are logged as warnings and allowed through, deliberately, for now. And it does not run on pull requests: it runs after code has landed on main, and nightly. It is a safety net, not a gate.

Game outcomes are announced badly, or not at all. The game stage is a polite live region, so for the HTML-based games a screen reader will read something when a round resolves — but what it reads is the raw stage text ("1.42×"), not a composed, useful sentence like "Bust. You lost 100 coins." No game calls the announcement API that exists app-wide, and balance changes are not announced anywhere. For the graphics-driven games (Plinko, the Wheel, the poker felt) the motion a sighted player reads the round from — the ball's path, the wheel slowing onto a segment — has no narrated equivalent at all. You get the final number without the round.

The poker felt is announced as a picture of nothing. Plinko's and the Wheel's canvases are hidden from screen readers; the poker table's animated felt is not. It is exposed as an image labelled with the table's name — so a screen reader announces a picture named after the table, and nothing whatsoever about the hand being played on it. The seats, chips and action buttons around it are real HTML, so poker is not unusable, but that canvas should be hidden like the other two and it is not.

Reduced motion works, but nothing enforces it. Every animated game checks your motion preference at its own call sites — the same check is written out separately in several places, and each new animation has to remember to make it. There is a shared animation scheduler in the codebase that would collapse a timeline straight to its end state for you, but no game currently uses it, and it assumes full motion unless it is explicitly told otherwise. So reduced motion holds everywhere I have checked, and there is no structural reason it will keep holding as games are added — only my care. Treat the "Motion-safe" promise below as a commitment, not a guarantee the architecture makes for me.

ARIA coverage is uneven. Sign-in, the responsible-play page, chat, the bet feed, the game control groups and the poker actions carry roles and labels. Plenty of other surfaces do not, and I have not measured the coverage rigorously enough to put a number on it.

High-contrast mode is half-shipped. The theme system supports a high-contrast palette and it is wired to your operating system's contrast preference: if you have "increase contrast" (prefers-contrast: more) set, Ganbate applies the high-contrast overrides. What is missing is the manual control — there is a place to store the preference, but no setting anywhere in the UI lets you turn it on or off yourself. Ganbate also does not currently respond to Windows forced-colours mode, and the high-contrast palette has never been checked against a contrast-ratio target.

Keyboard navigation is not tested end to end. Individual controls are focusable and dialogs cycle focus, but nothing in the test suite drives the site with the keyboard alone — not the lobby, not a game, not the cashier, not chat. The automated check audits each page as rendered; it never presses Tab. Until someone plays Ganbate through with a keyboard and nothing else, there will be problems here that I do not know about yet. The skip link above is exactly the kind of thing that pass would have caught — it sat broken until I read the code to write this page.

What I am aiming for

Not a badge. Three concrete things:

1. Keyboard-complete. Every action on Ganbate reachable and operable without a mouse, with a working skip link and dialogs that make the page behind them inert.
2. Screen-reader-sane. You can find a game, understand its state, place a bet, and hear a result that is a sentence rather than a stray number — including for the graphics-driven games, which need a text state layer built alongside the visuals.
3. Motion-safe. Already largely true, and made structural rather than remembered game by game — routed through the shared scheduler so a new game cannot animate past your preference by forgetting to ask.

Coins on Ganbate have no cash value: they cannot be withdrawn, transferred, redeemed or converted to money, and nothing you win can be turned back into money. That is the point of the whole site. But "the coins are not money" is not much comfort if you cannot use the thing at all — so the accessibility work matters on its own terms, not as a compliance chore.

Found a barrier? Tell me

Email [email protected] with Accessibility in the subject line.

I read accessibility reports before feature requests. What I cannot offer is a response time: there is no support team, no ticket SLA and no queue of agents — it is one person, and a reply may take a few days. If something on this site blocks you from using it, that is a bug of the highest kind, and I would rather hear about it bluntly than not hear about it.

It helps if you can tell me:

• what you were trying to do, and on which page
• what got in the way
• your assistive technology and browser, if you use one (for example: NVDA on Firefox, VoiceOver on Safari)

You do not need to know the correct terminology or cite a WCAG criterion. "My screen reader cannot tell me where the ball landed in Plinko" is a perfect bug report.

If a barrier stops you from reaching a part of the site you need — the cashier, a responsible-play control, self-exclusion, your account — say so, and I will help you get it done directly while the underlying fix is in progress. Nobody should be locked out of the tools that let them stop playing.

Related: FAQ · Support & Contact · Complaints · Provably Fair · Responsible Play

Ganbate is operated by Abraham Ahn, sole proprietor, California, Abraham Ahn, 5013 S Louise Ave, Unit #972, Sioux Falls, SD 57108, USA. Contact: [email protected].

Ganbate is a free-to-play social casino for adults 18+. Coins have no cash value. They cannot be withdrawn, cashed out, redeemed, transferred between players, gifted, sold, or traded. There are no prizes of monetary value. No real-money gambling takes place on this site.

Last reviewed: August 2, 2026. This page was written by reading the code, not from a template. When the fixes above land, this page changes with them — including the parts that make Ganbate look bad.