纯悬停触发的功能天然不可被键盘或屏幕阅读器发现

概念解释

功能的唯一触发器若是指针进入，键盘和屏幕阅读器发现不了它。这两种设备不产生「光标滑进矩形」这种事件：键盘走的是焦点，阅读器走的是线性化后的可访问树。悬停当作桌面自由来用时，自由的边界就是这两种输入的事件词汇里没有进入。

这条只谈发现：没有进入事件，这条功能不在他们的世界里。不谈如何把整个应用做成键盘可达，也不谈阅读器怎么读标题和地标。

机制

指针进入是一条空间事件，绑定在命中测试上。Tab 键移动的是焦点，焦点可以停在控件上，但默认并不会去派发指针进入，也不会去画那层只在 :hover 里出现的节点。屏幕阅读器浏览的是无障碍树：未挂到树上、或只在悬停时才插入树的按钮、说明、菜单，对阅读器等于从未存在。桌面把能力存进进入事件，等于把能力存进一种只有鼠标和触控板才会发的信号。键盘用户和阅读器用户不是「操作慢一点」，是根本没有这根信号线。

所以补救不是「把悬停延迟调短」。延迟再短，没有指针的人仍然发不出进入。要把同一功能挂到焦点、挂到常驻控件、或挂到阅读器能读到的名字上。桌面自由可以继续服务指针，但不能是唯一的调度器。

怎么研究

用键盘-only 协议走完任务：拔掉或禁用指针，只允许 Tab、方向键、回车、快捷键。另用屏幕阅读器走同一任务（浏览模式与焦点模式都走）。记录哪些步骤需要悬停才出现对象或才出现名字。

自变量：功能是否只挂在进入事件、焦点时是否露出同一内容、无障碍树上是否有对应节点。 因变量：键盘路径卡死次数、阅读器读不到的名称或控件数、误以为功能不存在。

用鼠标「顺便」把指针停在焦点上，会把失败测没。测试时指针要移开窗口或隐藏。

边界

已经用焦点复现了同一预览的界面，键盘用户发现得了，阅读器仍取决于那份内容是否进了无障碍树——两条通道要分开验。纯展示、不承载操作的装饰性悬停高亮，发现失败的代价是弱线索，不是丢功能。开关控制、语音控制同样不发指针进入，失败形态与键盘同类，不在这里展开。触屏的发现失败是迁移问题，机制不同：触屏有接触事件，只是没有进入。

怎么落地

• 凡是指针进入才出现的操作或说明，在焦点落到同一对象时也要出现，并保证对应节点在无障碍树里有名称。
• 不要用「鼠标移上去就有按钮」作为某条命令的唯一入口；菜单栏或常驻按钮里要有同一命令。
• 验证：隐藏指针，只打键盘完成每条主任务；再用阅读器听一遍同一路径。任何一步需要「先把鼠标移上去，否则没有这个控件 / 没有这段话」，就是纯悬停触发，发现已经失败。

延伸

• 同组：K2.06.1 悬停允许无承诺的预览与提示 · K2.06.2 依赖悬停的设计无法迁移到触屏 · K2.06.3 同一产品跨形态时需准备两套方案 · K2.06.4 悬停可用于渐进呈现次要信息，避免界面一开始就显得拥挤 · K2.06.5 悬停触发的时间阈值需要过滤路过式的鼠标移动 · K2.06.7 悬停态提供的信息若不可或缺，说明界面本身缺少必要的常驻线索
• 相邻：J3.01 键盘可达 · J5.01 屏幕阅读器 · D1.12 焦点、悬停与选中三者的区分
• 站内检索：hover-only · keyboard discoverability · pointer-enter dispatcher