The round is over. A retry button sits under the score. The mouse is across the room, or out of reach entirely. The question is small and immediate: can the next round start from here, using only a keyboard?
Start, pause, retry: three separate checks
Keyboard access is not a special bonus for the opening screen. WCAG 2.1 Success Criterion 2.1.1 says all functionality must be operable through a keyboard interface, apart from narrow cases where the task depends on a particular path, such as free-hand drawing. In a browser arcade game, Start, Pause, and Retry are ordinary controls. Each needs a keyboard route.
That rule does not ban the mouse. A player can click a button, tap it, or use a key. The gap appears when clicking is the only way to activate it. A keyboard user might have no vision, use an alternate keyboard or speech input, operate a scanning system, or have low vision. The input device changes. The control still needs to be reachable.
For a quick hands-on check, leave the mouse alone. Try moving focus to Start, activating it, pausing during play, and reaching Retry after a loss. The keys vary by game, so look for instructions and test the controls the game presents. If the path ends at a button that only responds to a click, record that as a keyboard gap. This is a practical spot check, not a conformance audit.
Feel the input, not just the result
Session log: opening screen. Focus moves. Start responds. Round begins. Pause responds once. Loss screen. Retry responds once.
The word “once” matters. The W3C guidance says keyboard operation cannot depend on a player repeating keystrokes within a short time or holding a key for an extended period. A control that wakes up only after a rapid double press can be technically responsive and still be hard to use. The same goes for a Retry action that needs a long hold while the game gives little or no indication that the input registered.
In a fast game, fingers tend to hurry. That is exactly where a clean single press helps: the action registers, and the player can tell what happened. A pause key should not require a timed combination just to stop the motion. Retry should not make a player guess whether the first press worked.
Pause has two jobs
There is the pause button a player chooses during a round, and there is the pause mechanism required for certain motion that starts on its own. They overlap in everyday language, but the WCAG criteria ask different questions.
Under 2.1.1, if pausing is a game function, it must be operable by keyboard. That applies even when the player deliberately pressed Start to begin a round. A game can offer both mouse and keyboard controls, but a keyboard user should not have to reach for a pointer to stop their own play.
WCAG 2.1 Success Criterion 2.2.2 covers moving, blinking, scrolling, or auto-updating content that starts automatically, lasts more than five seconds, and runs alongside other content. The guidance names real-time games as an example. It requires a way to pause, stop, or hide that content unless the motion is essential to the activity. The key detail is how it starts: a round deliberately launched by pressing Start is different from motion that begins automatically on a page.
Look at the screen before the first press
A browser game may show motion before the round begins. An automatic attract animation that keeps running beside other content raises a different question from the action the player chose by starting a game. If automatic motion continues past five seconds, look for a visible way to pause, stop, or hide it. Then check whether that control also works without a mouse.
There are exceptions. The W3C guidance says a preload animation can be essential when the player cannot interact during loading and omitting progress would cause confusion. It also says streamed or periodically updated content does not have to preserve information generated while paused. Those details keep the rule focused on usable control, rather than requiring every animation to freeze and resume exactly where it left off.
For the keyboard pass, make a separate note for each moment: before Start, during play, after losing. A control that works in one screen does not prove that the next screen can be operated the same way. The input path can change when the game moves from playfield to menu.
What the check can and cannot tell you
WCAG 2.2 was published as a W3C Recommendation on December 12, 2024, and extends the earlier guidance. Content conforming to WCAG 2.2 also conforms to 2.1 and 2.0. The keyboard and pause criteria discussed here come from WCAG 2.1, so they offer a clear baseline for asking about Start, Pause, and Retry.
But general guidance does not establish how any particular GamesUnlimited game handles those controls. It does not verify a site's sign-in, scores, chat, or text updates either. Those need direct checks. A short keyboard-only run can reveal a missing route, a stubborn held-key requirement, or a pause control that never comes into focus. It cannot, by itself, certify the whole game or site.
On the next round, keep the mouse untouched for one full session. Can you start, stop, and retry with the same confidence as a click? And when motion begins before you choose it, is there a keyboard-accessible way to make it wait?
Sources
He is a house writer for GamesUnlimited. He covers co-op campaigns, controller design, and player rituals through reports from launch nights and living rooms.
