Switch access relies on scanning—scanning speed must be adjustable

What it is

Switch access is assistive technology that compresses game input into one or two physical buttons—players with severe motor impairment may reliably control only a single movement. Under such input, the game must provide a scanning interface: the system highlights candidate options in sequence, and the player presses the switch when the target is highlighted. Scan speed determines that interface's usability: too fast and the player cannot react when the target highlights; too slow and every selection takes so long that any time-pressured game moment becomes infeasible.

Why it happens

A scanning interface's interaction cost structure differs completely from conventional input. Conventional selection costs nearly nothing (the finger is already on the button; pressing is selecting). Scanning selection costs "the average wait until the target highlights"—proportional to option count and inversely proportional to scan speed. Adjustable speed follows directly from that cost structure: every player's reaction window differs (reflex speed, the physical delay of pressing the switch), so a fixed speed is inevitably too fast for some and too slow for others. More critically, in-game decision pressure is not uniform—browsing menus can be slow, switching weapons in combat must be fast—and one scan speed cannot serve both, requiring per-context speeds or a mid-scan accelerate press.

Where it stops holding

Scan speed is not the only adjustable parameter. Scan grouping (linear item-by-item, row-column stepping, block grouping) often affects selection time more than speed itself—converting a ten-item linear scan into three-rows-by-three-columns stepping cuts average selection time by more than half—and both layers need exposing as settings. The scanning interface's constraint on game design is structural: any action relying on simultaneous multi-key or precise timing needs an alternative path under scan access (automatic execution, widened timing, simplified to a selection), reaching into gameplay mechanics' optional alternative rules, not just the UI layer. Switch users' fatigue profile also differs—repeatedly pressing one switch concentrates muscular load on specific muscle groups, so scan rhythm design must respect a press-frequency ceiling.

Applying it

• Provide scan speed as an independent slider (dwell per step across roughly 0.3–3 seconds) plus a mid-scan accelerate press to skip to the next group.
• Implement row-column stepping instead of pure linear scanning to cut average selection steps in large menus.
• Label every scanning option with its in-game action name so players never need to memorise highlight order.
• Verification: have a switch user (or a single-button simulation) complete a standard task set (open menu, switch weapon, cast ability) and measure average selection time and misselection rate. When the error rate exceeds threshold, adjust grouping first rather than simply slowing the scan further.

Related

• Same group: W8.04.1 One-handed play needs a redesign, not fewer buttons · W8.04.3 Simultaneous key presses need sequential-input alternatives · W8.04.4 One-handed modes must keep every core action, not amputate features
• Nearby: J1.02 Motor accessibility · J1.01 Accessibility design principles · W8.04 One-handed and switch access
• Search terms: switch access · scanning interface · row-column scanning · single switch gaming