J3.08.2switch access item countdesignresearch

The number of focusable items decides whether scanning stays usable

Aliases: focusable set size · scan stops · item count

What it is

A switch user does not face a layout. They face a list of stops. How long that list is decides whether scanning is usable. The count is not how many things are drawn. It is how many focusable nodes the scanner will halt on: decorative buttons, every toolbar icon, every social affordance, every tappable patch in a sheet.

Why it happens

Each extra stop is a tax on every task that has to pass it, not only on tasks that use it. A mouse can treat irrelevant controls as scenery. Scanning has no “skip with peripheral vision”: if a node is in the sequence, it costs a beat.

The list also diverges from what is on screen. Controls that have scrolled away, sit under another layer, or exist only for script, still stop the scanner if they remain focusable in the accessibility tree. A visually sparse page can still have an absurd stop list. Once the count is high, putting the primary button first is not enough: the queue itself is unusable. People time out, or they fire the switch on the wrong beat.

Studying it

With Switch Control on the target page, count actual scanner stops (not DOM node totals), then run three real tasks for completion.

Independent variables: focusable-node total, share of still-focusable but invisible nodes, whether every list row is exposed as its own stop. Dependent variables: stops per screen, task time, abandon rate.

Comparing “visual element count” with “scan-stop count” is diagnostic. A large gap means the tax is invisible focus, not overcrowded drawing.

Where it stops holding

A long read-only article with almost no controls is limited by order, not by count. Virtualized lists that only expose on-screen rows change the count as the user scrolls; a static census underestimates. Direct eye-gaze selection is governed by target size and spacing, not stop count; do not score an eye-gaze page with the scanning item-count test.

Applying it

  • Remove nodes that should never be stops: decorative controls out of the tab/scan set; collapse duplicate share rows into one container.
  • Do not expose every row and every in-row action as a stop by default; enter the list first, then open actions for the current row.
  • Verify: scan from the top of the page to the bottom and count out loud. If a routine task screen has a hundred stops, hunt invisible focus and duplicate toolbars before any other tuning.

Related

  • Same group: J3.08.1 Sequential scanning makes path length the cost of every action · J3.08.3 Grouping and regions cut the scan path
  • Nearby: J5.05 Switch and Eye-gaze Input · J3.01 Keyboard Access · J4.07 Cognitive Accessibility
  • Search terms: switch access item count · focusable set · scan stop

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/J3.08.2