Every Inkplay Game Plays Without a Mouse
Unplug your mouse; nothing on Inkplay stops working. Arrows or WASD steer Snake, and space pauses it. In Blocks the arrows shift and rotate the falling piece while space slams it home. Even Pinball — the most analog-feeling thing we've built — runs on three keys: space to launch, left and right arrows for the flippers. That's policy, not coincidence. Every game here ships keyboard-first, with pointer and touch controls layered on afterward.
Who keyboard-first is actually for
The unglamorous answer: most laptop owners. A trackpad is fine for spreadsheets and misery for games — you can't hold a direction, your finger drifts off the pad mid-move, and every click costs you a beat you don't have. A huge share of our players are on laptops with no mouse in sight, on sofas, trains, and school desks. For them, "works with keyboard" is the difference between playing and closing the tab.
The more important answer is motor accessibility. Keys are large, discrete targets that don't require steering a cursor across a screen, and for players with tremor or limited fine motor control that's a difference in kind, not degree. Keyboard-driven games also inherit the whole ecosystem built on top of the keyboard — OS-level key remapping, sticky keys, switch-access software that emulates keystrokes. We don't integrate with any of those tools individually. We don't have to. A game that's honestly keyboard-driven gets them all for free.
And the third answer is muscle memory. If you fed arcade cabinets or wore out a Game Boy d-pad in a previous decade, your hands already know these games. Where a game steers, we take arrows and WASD both — Snake answers to either — because left-handed players exist, and so do laptops with cramped arrow clusters. Meanwhile 2048 needs nothing but the four arrows, which is most of why it became the office game of 2014.
The hard part: sharing a keyboard with a webpage
A browser game lives inside a page that also wants the keyboard. Space scrolls the page. So do the arrows. There's a search box in the header. Get this wrong and you produce the two classic sins of canvas games: the page that lurches downward every time you jump, and the game that eats what you were typing into search. Half the angry comments under early HTML5 games were some version of the same five words — the page scrolled, I died. Avoiding both comes down to four decisions, applied everywhere:
- Listen at the page level, not the canvas. Our games take input from the whole window, so there's no click-here-to-focus ritual, and no way to accidentally click yourself deaf to the controls mid-run.
- Claim a key only when the game uses it. When a game consumes an arrow or space, it tells the browser to skip the default behavior, so the page underneath doesn't scroll. Every other key passes through untouched — Tab still moves focus, and your browser's own shortcuts keep working.
- Give text fields right of way. Every page carries a small guard, registered before anything else, that stops keystrokes from reaching game listeners whenever you're typing into an input or any editable field. Type a query with an s and a d in it into the header search while Snake is running, and the snake doesn't twitch. Your letters go to the box you're typing in, nothing else.
- Never trap the keyboard. The rest of the page stays reachable without a pointer — you can move focus to the fullscreen button, the how-to panel, and back out again. A game that hijacks every keystroke on the page is just a different genre of broken.
None of that is exotic engineering. It's a short list of decisions made once, early, and kept everywhere — which is exactly the kind of thing that quietly disappears when a site embeds a hundred games from a hundred different developers. Building every game ourselves, on one shared engine, is what makes the rule enforceable.
To be clear, keyboard-first doesn't mean keyboard-only. Every game also plays by pointer and touch — Snake steers by swipe on a phone, and the board games are all tap-driven — because a rule that punished half our visitors would be a strange kind of accessibility. First-class keyboard support just means the keyboard path is designed, tested, and never the afterthought. On a desktop, it's almost always the better way to play.
Motion, and the rest of the quiet checklist
Keyboard support is the loud half of practical accessibility. The quiet half is respecting what your device already told us. Both major operating systems let people ask software for reduced motion — a setting that matters enormously if you have a vestibular disorder, where a looping animation isn't an annoyance but a genuine reason to leave a page. If your system asks for it, Inkplay listens: the animated how-to demos on game pages freeze on a readable frame instead of looping at you. High contrast comes free with the house style, since every game is drawn in full-contrast grayscale to begin with — there's no low-contrast pastel mode anyone needs rescuing from.
Our internal test is blunt. Sit down with only a keyboard and play a full session — find a game, play it, go fullscreen, come back out. If any step genuinely needs the mouse, that's a bug, and it gets treated like one. Try the same experiment yourself tonight: trackpad off, ten minutes, starting with whichever of Snake, Blocks, or Pinball your hands remember best. Odds are they remember all three.