Sequential scanning makes path length the cost of every action

What it is

Switch access turns the interface into a queue. A highlight walks items in order; the user waits, then hits a switch. That process is switch scanning. A mouse or finger pays Fitts-style aiming distance. Scanning pays how many steps remain. Path length is the price of the action.

Why it happens

Scanning is serial. Automatic scanning advances on a clock; user-paced scanning advances one switch press at a time. Reaching the nth stop costs about n intervals, and a wrong hit often means re-queuing from the start. A large distant button is one tap on a touchscreen. Scanning cannot jump by spatial proximity: every focusable node in between is a toll.

The cost is locked before the task starts. The user already knows the target and still cannot map intent onto location; they can only wait for the queue. Two buttons that sit side by side on screen may be twenty stops apart in the scan. Visual proximity is not scan proximity. Scan order usually tracks keyboard focus order, but the set of stops is not always the same.

Studying it

Drive the platform scanner (iOS Switch Control, Android Switch Access, macOS Switch Control) with a hardware switch or a Space-key stand-in. From a fixed start, log steps and wall-clock time to a specified control.

Independent variables: ordinal position in the scan, auto-scan interval, auto versus user-paced. Dependent variables: step count, time, re-queue count after a miss.

Tab order is a cheap preview, not a substitute. Scanners differ from keyboard focus on which nodes stop the highlight and whether a container counts as one cell. Keyboard-only checks miss both “focusable but skipped by the scanner” and the reverse.

Where it stops holding

Dwell-based eye-gaze, head mice, and joystick pointer control are not sequential scans, so path length is the wrong model. Two-switch move-then-select is still sequential, but the user owns the tempo; fatigue is press count, not waiting. A very fast interval leaves the step count unchanged and raises errors. When a game uses scanning as the challenge, a long path is difficulty, not a defect.

Applying it

• Put high-frequency actions early in the scan, not after a long toolbar.
• Keep scan order aligned with reading order so the highlight does not jump around the screen.
• Verify: enable system Switch Control, walk three core tasks from one start, and count steps. If a routine task takes tens of stops, check whether the primary action is buried at the tail.

Related

• Same group: J3.08.2 The number of focusable items decides whether scanning stays usable · J3.08.3 Grouping and regions cut the scan path
• Nearby: J5.05 Switch and Eye-gaze Input · J3.01 Keyboard Access · J3.02 Focus Order and Focus Traps
• Search terms: switch scanning · scan path length · item scanning