Switch and eye-gaze bandwidth is tiny, so each selection is costly
Aliases: switch access · eye-gaze · low-bandwidth input
What it is
One switch, one blink, one second of dwell — that is one “OK.” Switch and eye-gaze crush human input into a thin pipe: a few bits per minute. A mouse click is nearly free; on these devices every selection is a bill in effort or time.
Why it happens
A switch is usually one or two binary lines. The user waits for a scan highlight to reach the target and then fires, or uses two switches for “next” and “select.” Eye-gaze uses looking as a pointer and dwell as a click. Both channels are limited by throughput: each selection waits out a scan cycle or a dwell threshold, plus aiming, anti-misfire, and fatigue. Errors are billed the same way — undo is another selection.
Bandwidth is low not because the person is slow, but because the device collapses continuous motion into sparse events. The in-between states a mouse pointer slides through must be expanded, on a switch, into an explicit series of steps. If the UI is designed as if clicks were cheap, every step is multiplied by seconds of waiting.
Studying it
Complete “open menu → pick one → confirm” with system Switch Access or eye-gaze. Count selections, wait per selection, wall time, mid-task rest. Compare the same task on touch or keyboard.
Independent variables: input channel (switch / gaze / pointer), dwell or scan period, selections the task requires. Dependent variables: completion time, selection count, fatigue breaks, extra selections after a miss.
Recruit people who actually use the device, or at least finish the task on the device. Do not “simulate a switch” with a mouse. Simulation misses the physiological cost of waiting and firing.
Where it stops holding
Dual-switch or head-pointer setups have somewhat more bandwidth, so the claim weakens, but they remain far below touch. In a short demo someone can push through one flow; long sessions are overturned by fatigue. When speech is a parallel channel, some selections can leave the switch; the hard constraint is for people who have only switch or gaze. How a scan path is grouped does not belong here — that is how the UI is arranged. Here the only question is how expensive one device input is.
Applying it
- Count the primary flow as if each selection costs seconds: how many selections to register, check out, send a message, and whether that product still finishes before fatigue.
- Do not split a confirmation that could be one selection into two; undo of a destructive action must be one selection back to the previous state.
- How to check: turn on Switch Access or eye-gaze, disable the pointer, finish one primary task. Count selections and wall-clock time. Every “just one more click” is one more cycle of waiting.