One-handed modes must keep every core action, not amputate features

What it is

A one-handed mode's value is decided by feature parity: with an alternative input scheme the player should be able to perform every core action—combat, exploration, menus, saving, social features. A "simplified" one-handed mode that cuts certain skills, skips certain activities, or disables certain systems turns accessibility into feature segregation: players using the accessibility option play a reduced version of the game, cannot participate in the full experience, and cannot compare progress with standard-input players on the same content.

Why it happens

Feature amputation is usually motivated by engineering cost—making a cut action work under alternative input requires redesign, and deletion is cheaper. But parity is the condition on which the accessibility promise is honoured: players choose one-handed mode because they cannot use the two-handed scheme, not because they want less content. A removed function is not an "optional convenience" for the players who need it but a "part they cannot join"—being unable to use a skill in an action game equals being unable to pass some level, so the feature gap converts directly into a progression block. Parity also bears on social identity: when accessibility-mode players are excluded from full achievements, multiplayer matching, or the content the community discusses, the isolation comes from system design, not ability difference.

Where it stops holding

Parity does not require equal execution efficiency for every action. Alternative inputs may be slower (scanning selection is an order of magnitude slower than a direct press), and that efficiency gap is acceptable as long as the game's time structure lets the player accomplish the same actions—in competitive matches an efficiency gap becomes a fairness problem and falls under the previous card's framework. Some content structurally depends on a specific input form (a motion game's core is physical movement), where full parity is physically impossible; the honest boundary is providing an alternative mode of participation rather than pretending the difference away—and disclosing the alternative's scope before purchase. Parity also runs in reverse: standard-input players should be able to use accessibility-designed assists (auto-QTE, widened timing). Accessibility features are universal optional capabilities, not the exclusive territory of a specific group.

Applying it

• Use the core-action inventory as the parity standard: at delivery, verify one by one that every action has a usable path in one-handed mode; any action without a path either gains an alternative or is explicitly flagged as out of scope for release.
• Player progression, achievements, and matching eligibility must not be restricted by using accessibility options, unless competitive rules explicitly declare so—and that declaration must be bound to a fairness argument.
• Verification: complete the entire game using one-handed mode and log every "cannot do this" or "content missing" moment into a parity-gap list. A non-empty list means feature parity has not been reached.

Related

• Same group: W8.04.1 One-handed play needs a redesign, not fewer buttons · W8.04.2 Switch access relies on scanning—scanning speed must be adjustable · W8.04.3 Simultaneous key presses need sequential-input alternatives
• Nearby: J1.01 Accessibility design principles · W8.01 Difficulty options and customisation · W9.01 Matchmaking and balance
• Search terms: feature parity · accessibility completeness · inclusive design · no-feature-loss