The number of elements decides whether the device is usable
Aliases: selectable item count · switch target count · gaze target density
What it is
Every extra selectable thing on screen is another wait for a switch user, another target an eye-gaze user has to hit. Element count on these devices is not a crowding issue. It is a bandwidth bill: N targets cost about N times as much. Past a point the task stops being slow and starts being unfinished.
Why it happens
Each input buys one event. A switch lights candidates one by one; a larger candidate set means a longer expected wait to the target. Eye-gaze spreads limited pointing precision over more targets; denser targets make dwell land on a neighbor. Both devices share a physical cap: only a few objects can be confirmed per unit time. Growing the selectable set is using count to punch through that cap.
This is not the same as “does it look dense.” Sparse visually, with dozens of focusable nodes in the tree, and the bill is still charged on the tree. Decorative hit areas, duplicate close buttons, and items inserted as the user scrolls all raise N. For pointer users N is almost free; for switch and gaze, N is whether the thing can be used.
Studying it
Same task, selectable or dwellable objects from few to many (8, 20, 40 per screen). Run Switch Access and eye-gaze. Watch time, misses, abandonment.
Independent variables: selectable objects per screen, object size (gaze), input channel. Dependent variables: completion time, miss count, incomplete rate.
Count nodes AT can actually select, not color blocks on the comp. Hidden-but-still-focusable nodes belong in N.
Where it stops holding
Many objects exist but the current context exposes only a handful (one layer open at a time) — effective N is the handful, not the page total. Gaze with large, sparse targets feels much less count pressure; a toolbar of tiny icons is unusable almost immediately. Users who can hand some selections to speech offload the count. Do not unpack “how to group the scan path” here — grouping arranges a path; here the only question is how large a candidate set the device faces.
Applying it
- Expose, at each step, only the objects the current decision actually needs; keep the rest closed.
- Do not stack a row of equivalent entries on one screen; duplicate close / share / like controls raise N linearly.
- How to check: turn on Switch Access or eye-gaze and count how many selectable objects you pass before the primary task finishes. If time scales with that count, or misses and quits begin, count is already deciding usability.