J3.08.2switch access item count设计研究
界面元素数量直接影响可用性
别名: 可聚焦数量 · 扫描停靠点 · focusable set size
概念解释
开关用户面对的不是布局，是一张要逐个停靠的清单。清单有多长，可用性就有多差。这里的数量不是屏幕上画了多少东西，而是扫描器会停下来的可聚焦节点有多少——装饰性按钮、底栏每个图标、每条社交入口、弹层里每一块可点区域，都算进这张清单。
机制
多出来的每一个停靠点，税不是只向「用得到它的任务」收。扫描要经过它，所有路过的任务都得付钱。鼠标可以把无关控件当背景忽略；扫描没有「余光略过」这一档，停靠点在序列里就占一拍。
更隐蔽的是清单和看见的界面不对齐。display:none 之外、被滑出视口、被其他层盖住、只为脚本存在的控件，只要还在无障碍树里可聚焦，扫描器仍会停。视觉密度低的页面，停靠点可以多得离谱。数量一旦上去，再怎么把主按钮排在前头，队列本身已经不可用——人等不到，也会在中途误触发。
怎么研究
在目标页打开开关控制，先数「扫描器实际停靠次数」（不是 DOM 节点总数），再抽三个真实任务看完成率。
自变量：可聚焦节点总数、不可见但仍可聚焦的节点比例、列表是否把每一行都暴露成独立停靠点。 因变量：单屏停靠数、任务完成时间、用户主动放弃的比例。
对比「视觉元素数」和「扫描停靠数」很有用：两者差得大，说明税来自不可见焦点，不是来自画了太多东西。
边界
只读浏览、几乎没有控件的长文，数量问题弱，顺序问题更突出。把长列表虚拟化、让扫描只进入当前窗口内的行，数量会随滚动变化，静态清点会低估。眼控直接点选按的是目标尺寸和间距，不是停靠点个数；不要拿扫描的数量判据去评眼控页。
怎么落地
- 先砍掉不该停靠的节点：纯装饰控件不要进 Tab/扫描集合，重复的分享条合并或移到一个容器里再进入。
- 长列表不要默认把每一行、每一个行内按钮都变成独立停靠点；先让用户进入列表，再展开当前行的动作。
- 验证：开关控制从页头扫到页尾，口头报数。一屏常规任务页停靠点上百，先查不可见焦点和重复工具条，再谈别的优化。