Switch-access scanning is the input method behind iOS Switch Control, Android Switch Access and most AAC boards: a person who cannot reliably point or tap uses one or two physical switches (a button, a sip-puff sensor, an eye-blink sensor) while the interface auto-highlights choices on a timer.
Row-column scanning cycles through each row on a fixed interval T. One switch press locks in the highlighted row and starts a second scan across that row's columns; a second press selects the cell. For an R×C grid, the number of scan steps to reach cell (r, c) is (r + 1) + (c + 1). Averaged over every cell, the expected step count is:
E[steps] = (R+1)/2 + (C+1)/2
time to select ≈ E[steps] × T
Linear (single-switch step) scanning highlights every one of the N = R×C cells in order, one press per step, so reaching item i costs i+1 steps — the expected cost over the whole grid is (N+1)/2, which grows with the grid's full area instead of just its perimeter-like R+C. That is exactly why real assistive-technology guidelines (WCAG 2.1 SC 2.2.1 "Timing Adjustable", Apple/Android accessibility docs) recommend row-column scanning for anything beyond a handful of items.
- Scan interval — the dwell time T per highlighted row/column/cell; too fast and a slow reaction time causes overshoot misses, too slow and selection takes longer than necessary.
- Press switch — fires exactly when the highlighted element matches what a real switch user would time their press to; press at the wrong moment and you select the wrong row/column, exactly like a real overshoot error.
- Hit rate / avg. selection time — measured live from your own presses, compared against the closed-form predicted time above.