QORPOInput accessibility: review one action across the whole game
To review input accessibility, follow one player action through the entire journey: reaching its setting, changing its binding, understanding the prompt, using it in play and recovering when something goes wrong. A remapping option is useful only when the player can reach it and the rest of the game respects the choice.
This article proposes a practical review for a small development team. It does not certify any QORPO product, claim that every accessibility option is implemented or replace testing with players who use different input methods. The worked example is hypothetical.
Start with an action that matters
Choose an action that blocks progress if it fails. Interact is a good example because it may open a door, collect an object or begin a conversation. Start by listing where the action is used rather than immediately changing its key.
For our example, a player needs to interact with a gate after configuring a comfortable binding. Success means more than seeing the new key in a settings row. The player must reach that row, understand the change, return to play and open the gate with the expected input.
Keep the review small enough to finish. One carefully traced action gives the team a concrete result and a pattern for the next action. A spreadsheet claiming that every control is accessible without performing those journeys gives less useful evidence.
Use established guidance as a baseline
Microsoft's Xbox Accessibility Guideline 107 treats input as more than remapping. It asks teams to consider demands such as speed, simultaneous inputs and prolonged activation, as well as alternative ways to operate the interface.
That is an important boundary: moving a difficult action to another button does not necessarily reduce its physical demand. A toggle or another interaction design may be worth considering, depending on the game.
Treat those as design questions to evaluate. The existence of a guideline does not prove that a particular option suits your game, that it has been implemented or that a player can complete every sequence.
Reach the setting without the missing capability
Imagine a player who can use a few digital inputs but cannot comfortably position a pointer. If the settings screen requires a precise mouse click before keyboard navigation becomes available, the remapping feature is behind the barrier it was meant to address.
For this model review, begin at a fresh launch with the chosen input method. Reach the options screen, move focus to the interaction binding and open its editing state. Note any step that unexpectedly demands a second device.
Do not silently help the test succeed by using your normal mouse. Record the point of failure. If a supported alternative path exists, test it explicitly and make sure the interface communicates it.
Change the binding and read the result
Assign a comfortable input, confirm the choice and return to the settings list. Does the row show the new binding? Can the player cancel an accidental edit? If another action already uses the input, is the conflict understandable?
The review should distinguish a deliberate conflict rule from a broken control. Some contexts can reasonably share an input. Two mutually exclusive menus may not need separate bindings. Two actions required at the same instant deserve closer attention.
Keep a simple record: original mapping, requested mapping, confirmation behavior and the displayed result. Avoid interpreting a successful screen update as proof that gameplay has also changed.
Carry the choice into the world
Return to the gate. Read the interaction prompt before pressing anything. It should describe the active configuration in a way the player can recognize, rather than displaying a hard-coded default.
Now perform the action. If the gate opens with the old key but not the new one, the settings interface and gameplay disagree. If the new key works but the prompt remains old, the player receives misleading guidance even though the binding itself succeeded.
These are different defects. A useful report names the mismatch precisely and includes the relevant context. The production evidence guide explains why passing one part of a journey does not establish the whole feature.
Look at duration and timing separately
Suppose opening the gate requires holding Interact. Changing the button may solve reach but leave fatigue unchanged. A separate model test can compare the supported hold behavior with an alternative, if the game offers one.
Similarly, a quick-time prompt can make the right binding unusable if the response window is too short for the player's input method. Do not assume that remapping resolves timing. Record what the action requires and which alternatives the current build actually provides.
This is where design and engineering need to meet. The answer might be a different interaction, a configurable option or a clearer prompt. A reviewer should describe the barrier without inventing a feature promise.
Check persistence and recovery
Save the setting through the supported interface, close the game normally and launch again. Verify the visible mapping, prompt and gate interaction in the same conditions. A setting that disappears on restart creates repeated work for the player.
Then check a recoverable mistake. Can the player restore one binding without resetting every preference? Can they exit an editing state after assigning an awkward key? A control screen should not trap someone inside the configuration they are trying to repair.
The save and recovery article covers persistence more broadly. For this review, the claim should stay narrow: the tested action retained its chosen mapping in the tested build.
Report what happened
A useful result names the device, build, action, contexts and actual observations. “Interaction can be rebound and used at the gate, but the tutorial still displays the default” tells a team what to fix.
Do not label that result full accessibility approval. A single action does not cover every menu, combat requirement, language, device or player need. It establishes a bounded test and identifies the next gap.
If AI helps draft the report or generate test cases, have a human compare the text with the observation. The AI code review workflow applies the same principle: persuasive output is not execution evidence.
Preserve the review context
Attach the selected binding, input device and settings profile to each recorded failure. Include whether the action followed a menu transition or a fresh launch. These details let another reviewer reproduce a confusing prompt without guessing which setup produced it. Retest the same sequence after a fix before closing the issue.
Common questions
Is system-level remapping enough?
It can help a player, but a game's own prompts and navigation can still create barriers. Test the actual route rather than assuming an external mapping makes every context coherent.
Should every game offer the same options?
Start with the demands of the game and the needs of its players. Established guidance helps frame the questions; product decisions and validation still require specific evidence.
Can a team claim certification after this review?
No. This is a practical test method, not a certification process or a statement about compliance.
Make one action work consistently
Choose a meaningful action, follow it without shortcuts and keep the evidence attached to the exact build. Then repeat for another action. That creates a review process a team can trust, while leaving room for player feedback to challenge assumptions.
Explore the QORPO blog for related development workflows and the studio live page for product progress.