Accessibility in Browser Arcade Games

A canvas element is, to assistive technology, a rectangle. It exposes no structure, no text and no semantics. Everything drawn into it — the character, the hazards, the score, the food — is invisible to a screen reader, because from the browser's point of view it is a single opaque image that happens to change sixty times a second.

That is a genuinely hard problem and it does not have a complete solution. What it has is a set of partial ones, each of which helps a specific group of people, and the honest approach is to implement as many as possible and then be specific about what remains unsolved.

This guide covers what we have done, why, and what we have not.

Keyboard parity

The most valuable single thing an arcade game can do. Every game on this site is fully playable with a keyboard alone — not as a degraded fallback but as an equal input path.

That consistency across thirty games matters as much as the coverage. A player who learns the scheme once does not relearn it per game, which removes an entire category of friction.

One technical detail that is easy to get wrong: a game must only swallow arrow-key and space presses while the play area has focus. A game that captures those keys globally breaks page scrolling for everyone, including keyboard users trying to read the instructions below it.

Instructions outside the canvas

Because the canvas is opaque, the game's controls must exist as real text in the DOM. Every game page on this site lists its full control scheme as an HTML list below the play area, with the key or gesture and the action it performs.

This is the single cheapest accessibility measure available and it helps far more people than the group it was designed for. A sighted player who forgot which key flips gravity is served by exactly the same list.

The stage itself carries an ARIA label saying what it is and pointing at where the instructions are: "Gravity Kitchen — playable canvas. Full controls and instructions are listed below the game." That does not make the game playable with a screen reader, and it is not pretending to. It tells someone what the rectangle is and where to find information about it.

Reduced motion

Vestibular disorders, migraine and motion sensitivity are common, and the web has a standard signal for them: the prefers-reduced-motion media query, set from an operating-system preference.

Respecting it properly means more than disabling CSS transitions. In a game it should change what the game draws:

• Particle budget drops to 25% of normal — 40 instead of 160.
• Background parallax stops entirely. Scenery is drawn statically rather than scrolling.
• Celebration effects are suppressed. Confetti bursts on a personal best are the most motion-heavy thing in the arcade and are the first to go.
• Screen shake is disabled completely.
• Star twinkle and bubble drift in the night and underwater themes hold still.

Crucially, none of that changes the gameplay. Speeds, hazard positions and scoring are identical. Reduced motion is a rendering preference, not a difficulty setting, and conflating the two would mean a player choosing between comfort and a fair score.

Colour independence

Around one in twelve men and one in two hundred women have some form of colour vision deficiency. A game that distinguishes food from hazards by colour alone is unplayable for a substantial number of people.

Two rules cover it:

1. Distinct silhouettes. Crates are square, cones triangular, whisks radial, rocks irregular, flames flickering. Shape carries the information and colour reinforces it.
2. Redundant channels on every indicator. Timer bars change colour and length. Hazards have a red glow and a distinct shape. A shield shows a coloured bubble and a HUD chip with an icon and a name.

There is a useful side effect: shape is processed faster than colour, so a design that works for colour-blind players is also more readable at speed for everyone.

Touch target size

WCAG 2.2 sets a minimum target size of 24 by 24 CSS pixels. The earlier enhanced criterion suggested 44. For a control pressed repeatedly under time pressure, neither is generous.

This site uses 64-pixel circular buttons, reduced to 58 on small screens, positioned in the natural thumb arc at the bottom corners and never overlapping the score display. That matters for motor accessibility specifically: a smaller target requires more precision, and required precision is exactly what a tremor or limited fine motor control makes difficult.

Difficulty as an accessibility feature

This is underrated and worth stating directly: difficulty options are an accessibility feature.

A player with slower reaction time — through age, medication, fatigue or disability — is excluded from a game with one fixed speed. The same game with four presets is available to them.

What makes a difficulty preset genuinely accessible rather than cosmetic is that it changes more than speed. On this site, Easy provides:

• 82% scroll and fall speed
• 20% fewer spawns and 35% fewer hazards
• A 90-second difficulty ramp instead of 70
• Four lives instead of three
• A 25% larger pickup radius

That last one is the accessibility measure. Reducing speed alone produces a slow version of the same precision requirement; widening the pickup radius reduces the precision requirement itself.

Presets are also remembered per game, so a player never has to re-select their setting — which is a small thing that matters a great deal to anyone for whom each interaction has a cost.

The single-input game

One-Tap Food Catcher is the most accessible game on this site and it was designed that way deliberately.

It requires exactly one discrete input. No direction, no hold, no aim, no simultaneous presses. Space, Enter or a tap anywhere on the play area all work identically.

That specification means it is playable with almost any adaptive input device — a switch, a sip-and-puff controller, a head pointer, an eye-tracker configured to dwell-click. Anything that can produce one signal can play it.

It also has no failure spiral: a miss widens the catch band by 8%, so a run always ends on a genuine mistake rather than on an unrecoverable narrowing.

Pause and interruption

Every game pauses instantly with P or Escape, and every game pauses itself when the browser tab is hidden, using the Page Visibility API.

That second behaviour is an accessibility feature as much as a convenience one. A player who needs to look away — for any reason, at any time — should not lose their run for it. Nothing about an arcade game requires uninterrupted attention to be enforced by the software.

Focus visibility

Every interactive element on this site has a visible focus indicator: a 3-pixel solid outline in a high-contrast blue, offset from the element, that does not rely on colour alone to be perceptible.

The outline is never removed. A design that hides focus rings because they are considered unattractive makes the site unusable for keyboard navigation, which is a considerably worse aesthetic problem.

What we have not solved

Being specific about limitations is part of doing this honestly.

• These games are not playable with a screen reader. The gameplay is spatial and real-time; a text description cannot convey the position of a falling item accurately enough or quickly enough. We provide context and instructions, not playability.
• There is no audio-only mode. Building one would mean designing games around audio positioning from the start, which is a different project rather than an adaptation.
• Key remapping is not available. Multiple bindings exist for every action — arrows and WASD, Space and Enter, Z and X and E — but a player cannot define their own.
• There is no colour-blind palette mode. We rely on shape distinction instead, which we believe is more robust, but a dedicated palette would help some players further.
• Timing games remain inaccessible to some players. Difficulty presets widen the windows but cannot eliminate the requirement.

Those are real gaps. Some are solvable and are worth doing; some would require the games to be different games. If any of them affects you, telling us is genuinely more useful than any audit we could commission.

An accessibility checklist for canvas games

1. Is every action available from the keyboard alone?
2. Are the controls listed as real text outside the canvas?
3. Does the canvas carry an ARIA label describing what it is?
4. Does prefers-reduced-motion genuinely change what is drawn, without changing gameplay?
5. Is there an in-page motion toggle for people who have not set the OS preference?
6. Is every hazard distinguishable by shape, not only by colour?
7. Does every indicator use at least two channels?
8. Are touch targets at least 44 px, and preferably larger?
9. Do difficulty presets change precision requirements, not just speed?
10. Does the game pause instantly, and pause itself when the tab is hidden?
11. Is the focus indicator visible on every interactive element?
12. Are the known limitations documented rather than glossed over?

Frequently Asked Questions