Of every design principle we apply at Suntongames, accessibility is the one that is most often called a "nice to have" by people who have not tried to ship it. The framing is exactly backwards. Accessibility is not a bonus layered onto a finished game. It is a constraint you either design with from the first prototype or retrofit badly at the end. The retrofit version is more expensive, more brittle, and almost always shipped late enough to lose the players it would have helped. The from-scratch version is cheaper, ships with the game, and — conveniently — makes the game better for everyone, not just the players it was nominally designed for.
This article is about the latter approach. I want to walk through the five accessibility commitments we apply to every casual puzzle we ship, the standards they sit on top of, and the surprisingly simple engineering decisions that make them work in a browser-based game.
The Standard: WCAG 2.1 AA as Our Floor
Every accessibility decision we make is measured against a single, public specification: the Web Content Accessibility Guidelines (WCAG) 2.1, at the AA conformance level. The guidelines, maintained by the W3C Web Accessibility Initiative (WAI), are the closest thing the web has to a shared accessibility contract, and we treat them as our floor, not our ceiling. WCAG 2.1 AA covers contrast ratios, text resizing, non-text contrast, target size, reflow, and a long list of other criteria that map almost one-to-one onto the casual puzzle experience. We do not always hit AAA, which is the strictest tier — AAA is intentionally hard, and some of its criteria conflict with aesthetic choices we are unwilling to compromise. AA is the line we ship against, every release.
The standards exist because the web's default — color-only signaling, tiny tap targets, motion-heavy UI — systematically excludes a meaningful share of players. The share is large enough that designing around it is not charity. It is a measurable improvement to a game's addressable audience. The standards just give us a shared vocabulary for what "good enough" means, so we do not have to relitigate every decision from first principles.
Color-Blind Friendly Design: Contrast and Shape Cues
Color-only signaling is the single most common accessibility failure in casual puzzle games, and also the easiest to fix. Roughly 8% of men and 0.5% of women have some form of color vision deficiency, with deuteranopia (red-green) the most common. For a genre that, at its core, often asks players to sort or match colors, this is not an edge case. It is a primary use case. A color-sort puzzle that relies on hue alone is, for one in twelve players, an unsolvable puzzle.
Our approach combines two things: WCAG 2.1 AA contrast ratios between adjacent colors and the background, and shape and pattern cues layered on top of every color signal. The contrast requirement is straightforward: any two adjacent elements that a player needs to distinguish must clear the AA contrast threshold of 3:1 for non-text graphics (and 4.5:1 for text). We test every palette against this with the contrast-checker toolset maintained by WebAIM, and we reject palettes that pass the perceptual test for typical vision but fail for simulated deuteranopia, protanopia, and tritanopia.
If a player can sort every level using only luminance and shape, you have designed an accessible game. If they need hue to do it, you have designed a game for the 92%.
The shape-cue layer is what closes the gap. In Wizard Sort, every color also has a distinct shape rendered inside the liquid — a circle, triangle, square, diamond, and so on. In Royal Matcher, each gem has both a hue and a facet pattern, so a player who cannot distinguish red from green still reads the cut of the gem. The pattern is not a toggle. It is always on. That matters: the players who need it most are often the players least likely to dig through a settings menu to enable it.
Touch Targets: The 44-Pixel Minimum
The 44×44 pixel minimum touch target comes directly from WCAG 2.1 Success Criterion 2.5.5 (Target Size, AAA). We apply it as our AA-floor default for every interactive element, because casual puzzles are played one-handed, often distractedly, on screens that range from a 4.7-inch phone to a 13-inch tablet. A 44-pixel target is not about being polite to clumsy thumbs. It is the empirical lower bound for accurate tapping under realistic conditions — and the realistic conditions of a casual puzzle include playing on a moving train, holding a baby, or playing with one hand while the other holds a coffee.
The implementation is unglamorous but worth spelling out, because most casual games get it wrong by accident. Every interactive element gets a minimum 44-pixel hit area, even when the visible graphic is smaller. The visible graphic can be smaller; the hit area cannot. We do this by wrapping small visuals in transparent touch pads sized to the minimum, and we make sure adjacent targets do not overlap into each other's hit areas. The most common failure we see in competing games is the inverse: the visual is large but the hit area is a sub-pixel subset of it, often only the exact center of the visual. The game looks tappable; it is functionally not.
Animation and prefers-reduced-motion
The third commitment is one we resisted for too long: respecting the user's prefers-reduced-motion system setting. The resistance was aesthetic. Puzzle games lean on motion — drops, cascades, pops, celebrations — to signal feedback. Cutting motion felt like cutting the game. The reality, once we actually tested it, was the opposite. The players who request reduced motion are not asking for a worse game. They are asking for a game that does not make them motion-sick.
WCAG 2.1 Success Criterion 2.3.3 (Animation from Interactions, AAA) directly addresses this, and the W3C WAI guidance on it is clear: animation should be avoidable when it is not essential. Our implementation checks the CSS media query prefers-reduced-motion: reduce at game boot, and when set, the game swaps long tween animations for near-instant state transitions with brief opacity fades. The mechanic is identical. The feedback is identical. Only the duration changes. Players who do not set the flag get the full motion experience. Players who do get the same game without the nausea.
Motion is feedback, not flavor. If you can deliver the same feedback in 40 milliseconds instead of 800, you have not removed the game. You have removed a barrier.
We learned one nuance the hard way: the reduced-motion swap should not be a binary "all or nothing." Cascades still need to read as sequential, not simultaneous, or the player loses track of which move caused which effect. Our current implementation keeps the order of animations and only compresses the duration of each. That single distinction was the difference between accessible and unplayable.
Typography and Readable Color
Typography is the most under-discussed accessibility decision in casual games, because most puzzle UI is graphical rather than text-heavy. But the moment a player sees a tutorial hint, a level-number badge, a score popup, or a settings menu, typography matters. Our floor here is also WCAG 2.1 AA: 4.5:1 contrast for body text, 3:1 for large text (over 18pt regular or 14pt bold), and a minimum body text size of 16px at the default viewport. We test against the WebAIM contrast checker for every text-on-background pairing we ship.
The other typographic commitment is the one players notice without ever articulating: we never encode game state purely in color. If a level is locked, the lock has both a muted color and a padlock icon. If a power-up is depleted, the depleted state is conveyed by a grayscale filter and a strikethrough and a disabled hit area. Three redundant signals for one state. To a player with full color vision, it looks like clear UX. To a player with low vision, it is the difference between a usable game and an opaque one.
Alternatives to Precise Input
The last commitment is the hardest, and it is the one the casual puzzle genre is uniquely positioned to deliver well: alternatives to precise input. Many players cannot perform the kind of precise tap-and-drag gestures that a sort or match puzzle nominally requires — players with motor impairments, tremor, or simply players on a bumpy commute with one thumb. For these players, the question is not whether the game is theoretically playable. It is whether the game offers a usable alternative path to the same outcome.
Our design choice is to layer tap-first interactions underneath every drag-based mechanic. In Wizard Sort, the player can either drag from one tube to another, or tap a source tube then tap a destination tube. Both paths produce the same move. In Royal Matcher, the player can either swipe a swap or tap the first gem then tap the second. The drag is the preferred, faster path for players who can use it. The tap is the fallback for players who cannot. Neither is gated behind a settings toggle. Both are always available, and the game silently accepts whichever input pattern the player offers.
This is, structurally, the same approach we take to every accessibility commitment: the accessible path is not a separate, slower, lower-quality experience. It is a parallel path to the same experience, available by default, invisible to players who do not need it and load-bearing for players who do. That is the philosophy. The standards give us the spec. The engineering gives us the implementation. The philosophy is what makes us apply both.
What Accessibility Buys — And For Whom
The case for accessibility is often framed as a moral one. It is also that. But the practical case is more interesting. Every accessibility commitment we ship improves the game for players who do not nominally need it. Touch targets that work for tremor also work for distracted one-handed play on a moving train. Reduced-motion mode also helps players on battery-saver mode and low-end devices. Color contrast that works for color-blind players also works for players in bright sunlight on a reflective screen. The curb-cut effect — named for the sidewalk ramps originally mandated for wheelchair users and now used by everyone with a stroller, a suitcase, or a bike — is not a metaphor here. It is a measured outcome.
If you take only one thing from this article, take this: accessibility is not a feature you ship for some players. It is a discipline you ship for all players, including the ones who do not know they are benefiting from it. The standards are public, the engineering is straightforward, and the only thing standing between a casually accessible game and a casually exclusionary one is whether you decided to do the work up front. We decided to do the work up front. The next paragraph you read on this site is the result.