J5.05.2switch access item count设计研究
界面元素数量直接决定可用性
别名: 可选元素数量 · 开关目标数 · 眼控目标密度
概念解释
屏幕上每多一个可被选中的东西，开关用户就多付一次等待，眼控用户就多一个要对准的靶。元素数量在这类设备上不是拥挤问题，是带宽账单：N 个目标大约是 N 倍选择成本。数量一大，任务会从「慢」变成「做不完」。
机制
输入每次只买一个事件。开关要把候选一个一个点亮，候选集越大，走到目标的期望等待越长；眼控要把有限的注视精度摊到更多靶上，靶一密，停留更容易落在邻居上。两种设备的物理上限都是「单位时间只能确认很少几个对象」，界面把可选集合做大，就是在用数量去打设备的上限。
这和「看起来密不密」不是一回事。视觉上疏、树上却挂着几十个可聚焦节点，账单按树来算。装饰性可点区域、重复的关闭按钮、随滚动不断插入的条目，都会把 N 抬上去。对指针用户 N 几乎免费；对开关和眼控，N 就是能不能用。
怎么研究
同一任务，把可聚焦或可停留的对象从少做到多（例如每屏 8、20、40），用开关控制和眼控各走一遍，看完成时间、误选、放弃。
自变量：每屏可选对象数、对象大小（眼控）、输入通道。 因变量：完成时间、误选次数、未完成率。
数的是辅助技术实际能选中的节点，不是设计稿上的色块。隐藏但仍可聚焦的节点要算进去。
边界
对象虽多但当前上下文只暴露一小撮（一次只开一层），有效 N 是那一小撮，不是整页总数。眼控在大靶、低密度时数量压力会小很多，小图标工具栏则几乎立刻不可用。能把选择交给语音的用户，数量压力会分流。不要在这里展开「怎么把扫描分成几组」——分组是在排路径；这里只问设备面对多大的候选集。
怎么落地
- 把每一步暴露的可选对象压到当前决策真正需要的那些，其余先收起来。
- 同一屏不要堆一整排等价入口；重复的关闭、分享、喜欢会把 N 线性抬高。
- 验证：打开开关控制或眼控，数完成主任务前要经过多少个可选对象。对象数一多完成时间就按比例涨、或开始误选放弃，数量已经在决定能不能用。