Accessibility in arcade games — an honest audit of our own

Fast, visual, canvas-based games are among the hardest things on the web to make accessible. Here's what genuinely helps, what's mostly theatre — and a frank account of where our own games currently fall short.

Written by the developer of Alftanet · Updated 13 August 2026

Most writing about web accessibility assumes documents: headings, alt text, focus order, screen readers. All of that is real and none of it maps cleanly onto a game rendered into a single <canvas> element, which to assistive technology is one opaque rectangle with no structure inside it at all.

So arcade games need a different set of questions. We went through ours recently and the results were mixed enough to be worth publishing rather than quietly fixing.

The things that help most

Never encode information in colour alone

This is the highest-value rule in games, and the easiest to break without noticing. If the dangerous thing is red and the safe thing is green, roughly one in twelve men and one in two hundred women will have a materially worse time — and red-green is only the most common of several variants.

The fix is rarely to change the colours. It's to add a second channel: shape, motion, outline, size, sound. A hazard that is red and spiky and pulses is readable by everybody, and honestly reads faster for players with typical colour vision too. Redundant encoding isn't a concession, it's better design.

Respect reduced motion

Browsers expose a system setting — prefers-reduced-motion — that tells a page the user has asked for less movement, usually because motion triggers nausea or vestibular symptoms. Honouring it costs almost nothing.

In a game you generally can't remove the motion that is the game. But you can remove everything around it: screen shake, parallax backgrounds, particle bursts, flashing transitions between states. Those are the effects most likely to cause problems and least likely to be load-bearing.

Don't rely on precise, sustained input

Timed holds, rapid repeated presses and precise drags all exclude players with motor impairments, and they're rarely the interesting part of a design. A one-button game where the button is a single tap is dramatically more playable than one requiring a held input of an exact duration — and usually a better game anyway.

Let the player see it at all

Small text on a canvas doesn't respond to the browser's zoom the way page text does, so a HUD that's readable on your monitor may be illegible on a laptop. Contrast matters more in games than in documents because the background is moving.

Where our games actually stand

Here's the uncomfortable part. We audited all fourteen and found more gaps than we expected.

What we do reasonably well

Input is simple almost everywhere. Most of our games are one button or one thumb. No timed holds of exact durations, no rapid mashing, no drag precision. That was a design preference rather than an accessibility decision, but it's the single thing that makes them broadly playable.
Nothing requires a mouse and a keyboard at once. Every game works with one input device.
No time-limited menus. You can sit on any start screen indefinitely.
The surrounding pages are proper HTML — real headings, real links, real text — so everything about a game is navigable even where the game itself isn't.

What we don't do, and should

Reduced motion is honoured in exactly one game. Of fourteen titles, only Castaway currently responds to the setting. Several of the others have screen shake and particle effects that would be straightforward to gate behind it. This is the clearest, most fixable failure on the list.
No colour-blind modes anywhere. None of our games offer alternate palettes. Some are fine regardless — Sonar is monochrome by nature and distinguishes things by shape and motion. Others lean on colour more than we'd like.
No in-game text scaling. HUD sizes are fixed relative to the canvas.
No audio cues as a substitute for visual ones. Our sound is atmosphere, not information. A player who can't see a hazard coming gets no warning they could hear.
Canvas contents are invisible to screen readers. This is true of essentially every canvas game, and genuinely hard to solve for a real-time action game — but "everyone else has this problem" isn't the same as it not being a problem.

The awkward case: a game built entirely on colour

Then there's Huedle, our daily puzzle, where the entire task is guessing a colour. There's no redundant-encoding trick that saves this one. For a player with significant colour vision deficiency, the core mechanic is partly or wholly inaccessible, and no amount of careful UI work changes that.

We think it's worth being direct about this rather than pretending otherwise. Some games have a premise that excludes some players — a rhythm game excludes on hearing, a colour game excludes on vision. The honest responses are to say so plainly, to make sure it isn't the only thing you offer, and to fix the parts that are fixable.

On that last point there is something concrete: Huedle's feedback after each guess is directional and banded — higher or lower on hue, saturation and lightness, and how far off you are. That's numeric information about a colour, which means a substantial part of the puzzle is playable by reasoning rather than by seeing. Making those hints more prominent and more precise is a real accessibility improvement, and it's on our list.

What we're changing

Publishing an audit is easy; the point is what follows it. In priority order:

Reduced motion across all fourteen games. Gate screen shake, parallax and particle bursts behind the media query. This is a small change per game and the biggest single win available.
A redundant-encoding pass. Go through each game and find anything distinguished by hue alone, then add shape or outline. We already suspect a couple of offenders.
Larger HUD text where it's currently tight, and a contrast check against moving backgrounds rather than static ones.
Stronger numeric feedback in Huedle, so the puzzle can be reasoned about as well as seen.

We'll update this page as those land, with dates, so it stays an audit rather than a statement of intent.

Found something in one of our games that's hard to play, for any reason? We'd genuinely like to know — contact@alftanet.com.

If you're building something similar

The advice we'd give from this exercise is to do the audit early, because the cheap fixes are only cheap before you've built fourteen of something. Reduced motion costs one media query if you think of it at the start and fourteen small refactors if you don't.

And be suspicious of accessibility work that's easy to demonstrate but doesn't help anybody — adding ARIA attributes to a canvas that contains nothing navigable is a good example. The things that actually matter here are unglamorous: don't rely on hue, don't demand precise timing, honour the motion setting, make the text big enough. None of it shows up in an automated checker, which is precisely why it gets skipped.

→ Play our games · → Why one-button games are secretly the hardest