Accessibility basics for small mobile games

Small game teams rarely have an accessibility budget, and the usual plan is to “do a pass” before launch. By then most of the important decisions are already made: how big the text is, which colours carry meaning, how far apart the buttons sit, whether anything flashes. The good news is that the barriers that stop the most players are also the cheapest to avoid if you think about them while sketching. This guide collects the basics for a mobile game, drawn from the Game Accessibility Guidelines, Apple’s and Google’s platform guidance and WCAG 2.2, with the official numbers where there are numbers to quote.

Start from the basic guidelines

The Game Accessibility Guidelines are the most practical reference I know for games. They’re grouped by the kind of ability involved (motor, cognitive, vision, hearing, speech and general) and split into three levels. Basic guidelines are easy to implement and help a wide range of players. Intermediate ones need some planning. Advanced ones are complex adaptations for profound impairments or particular mechanics.

For a small mobile game, the basic level is the right place to start. Almost everything below maps to one of its items. You can treat the list as a design checklist before you build menus or HUDs, not a test to pass at the end.

Make text readable on a phone

The guideline is simply “Use an easily readable default font size.” Apple’s design tips give a floor for iPhone apps: text should be at least 11 points so it’s legible at a typical viewing distance without zooming. Treat that as a minimum for incidental labels, not a target for the text players need to read during play.

Contrast matters as much as size. Android’s accessibility guidance asks for a contrast ratio of at least 4.5:1 for text smaller than 18sp (or bold text smaller than 14sp), and at least 3:1 for larger text. WCAG 2.2 uses the same 4.5:1 and 3:1 thresholds for normal and large text.

Games make this harder than ordinary apps because text often sits on top of moving art. A semi-opaque panel behind HUD text, or a solid outline round the letters, keeps contrast stable whatever the background is doing. Check contrast against the busiest frame of your game, not the calmest one.

Never let colour carry the meaning alone

The basic guideline reads: “Ensure no essential information is conveyed by a fixed colour alone.” WCAG 2.2 has the same rule for the web as success criterion 1.4.1, Use of Color, and asks for a contrast ratio of at least 3:1 for the graphics and interface parts people need to understand what’s going on.

In practice, pair every colour with a second signal. Friendly and enemy units can differ in shape or outline as well as colour. A tile that’s “ready” can show an icon, not just turn green. A health bar can show a number or change length, not only turn from green to red.

Size touch targets for thumbs

This is where the official numbers are clearest. Apple’s design tips say controls should measure at least 44 by 44 points so they can be tapped accurately with a finger. Android’s guidance recommends at least 48 by 48 dp for each interactive element, and adds that larger is better. WCAG 2.2 sets a minimum of 24 by 24 CSS pixels for pointer targets on the web, at level AA, with some exceptions.

The game guideline adds the part that platform numbers miss: interactive elements and virtual controls should be “large and well spaced, particularly on small or touch screens.” Spacing matters as much as size when two buttons sit next to each other and a mistap costs the player a move.

In a game, the tappable area doesn’t have to match the art. A small, neat icon can have a generous invisible hit area around it. That keeps the screen clean without making players hunt for a few pixels.

Captions and sound cues

Mobile games get played on trains and in waiting rooms, often with the sound off. Two basic guidelines cover this: “Provide subtitles for all important speech” and, if subtitles are used, “present them in a clear, easy to read way.” A third covers everything else: “Ensure no essential information is conveyed by sounds alone.”

If a sound tells the player that an enemy is coming, a timer is running out or a move was invalid, there should be a visual signal for the same event. Captions should sit on a background that keeps them readable, use a decent size and stay on screen long enough to read.

Motion, flashing and reduced motion

The basic guideline asks you to “Avoid flickering images and repetitive patterns.” WCAG 2.2 is specific for the web.

Both phone platforms also give players a system-wide way to ask for less motion. On iPhone, Reduce Motion (Settings, Accessibility, Motion) replaces zoom and slide transitions with dissolves and turns off parallax effects. On Android, the Remove animations option sits under Accessibility, Colour and motion, and Google describes it as being for people who experience motion sickness, photosensitivity or seizure triggers.

A game can read those settings and respond: soften screen shake, shorten camera moves, swap big zooms for fades. WCAG 2.2 has a level AAA criterion that motion animation triggered by interaction can be turned off unless it’s essential. That’s a high bar for a web page, but a sensible default for a game menu.

Haptics as an extra channel

Vibration is a good way to confirm a tap or warn of danger, but not everyone wants it, and some players find it uncomfortable. The basic guideline is short: “Include toggle/slider for any haptics.”

Treat haptics the way you treat sound. They reinforce what the screen shows. They shouldn’t be the only way a player finds out about something important.

Simpler controls and one-handed play

Two basic motor guidelines apply directly to touch games: “Ensure controls are as simple as possible, or provide a simpler alternative” and “Allow controls to be remapped / reconfigured.”

On a phone, remapping usually means layout options more than key bindings. Can a left-handed player move the main controls to the other side? Can a player who holds the phone in one hand reach everything they need? Portrait layouts suit one-handed play, as long as the controls that matter sit within reach of a thumb. Narrow Front, the strategy game I make at Matterward Labs, is played in portrait on a phone held in one hand, and that shape decided a lot of its design. Wherever your game sits, check where the most-used controls are before the layout hardens.

Gestures deserve the same scrutiny. A long press, a two-finger gesture or a precise swipe can be hard for some players. If a gesture is essential, offer a plain tap alternative.

Difficulty and time pressure

“Offer a wide choice of difficulty levels” is a basic guideline, and it’s more than a tidy menu. Time limits, reaction-speed checks and long sequences without a checkpoint are the places where players most often get stuck for reasons that have nothing to do with understanding the game.

Puzzle games have their own versions of these options: an undo button, a hint, the ability to pause anywhere, a mode without a timer. If you make puzzle games, as I do with Siren Jam, these belong on the first list of features rather than the last. Small additions like these can turn a level that some players can’t finish into one they can.

Test with the tools you already have

Accessibility checks don’t need a lab. On Android, Google points developers to the Accessibility Scanner app for checking contrast, and Play Console’s pre-launch report includes accessibility issues among its automatic tests. I covered the pre-launch report in getting through Google Play’s closed testing requirement.

Beyond the tools, play your own game the way some of your players will:

• with the system font size turned up
• with reduced motion switched on
• with the sound off
• in greyscale
• with one hand

Each run takes a few minutes and tends to show problems no checklist will.

None of this makes a game fully accessible. That depends on the game and on listening to the players who use it. The basics, though, cost very little when they’re part of the first sketch, and a lot more when they’re retrofitted a week before launch.