浏览模式与焦点模式的切换决定按键的行为方式
别名: 浏览模式 · 焦点模式 · forms mode · 虚拟光标
概念解释
同一颗 H 键，在阅读器里不是同一个命令。浏览模式（browse mode，虚拟光标）下它跳到下一个标题；焦点模式（focus mode，也叫 forms mode）下它只是往输入框里打出一个字母。模式切换决定的是：这组按键此刻被阅读器截走，还是被交给当前焦点控件。不是用户爱不爱用标题导航，是键盘事件的归属权。
Windows 网页阅读器上这条分界最硬。NVDA 用 Insert+空格切换，JAWS 也有对应开关；进入原生文本框、列表框时常常自动跳进焦点模式，离开再跳回。
机制
键盘只有一套。浏览模式里，阅读器是第一个消费者：方向键移动虚拟光标，单字母快捷键按角色跳转，数字和标点也常被征用。焦点模式里，阅读器放手，事件进控件——方向键改选中项，字符键输入，快捷键走应用自己的绑定。
第二层是自动切换的触发条件。阅读器根据角色判断「这是一个要吃键的控件」：textbox、combobox、listbox、slider 会把模式拽过去；一堆 div 即便画得像列表，角色仍是无，阅读器就停在浏览模式。于是用户按方向键，虚拟光标离开了这组「选项」，真正的选中状态一步没动。自定义组件最常在这里翻车：外观像控件，键盘消费者还是阅读器。
怎么研究
在同一张含表单和正文的页面上，记录每次按键时的模式（NVDA 状态栏、JAWS 提示音）和实际效果。任务分成两截：只读浏览一段文章；把焦点放进输入框再输入、用方向键改下拉。Windows 用 NVDA+Firefox 与 JAWS+Chrome 各跑一遍；VoiceOver 的 Quick Nav / 「与控件交互」是同源分界，名称不同，不要用 Windows 的 Insert 键去测。
自变量：角色是否为标准表单控件、是否手写键盘处理、是否有自动模式切换。 因变量：按键被谁消费、任务是否完成、用户是否需要手动切模式才能继续。
边界
iOS VoiceOver、Android TalkBack 没有 Windows 网页那种「整页浏览模式吞单键」的模型，手势和转子才是主通道，不能拿 H 键当判据。桌面原生应用里，焦点几乎总在控件上，浏览/焦点二分弱得多。游戏、编辑器和自定义快捷键会与浏览模式的单字母跳转抢键；阅读器用户若关掉单键导航，失败模式会换一种样子，而不是消失。自动切换在 iframe、影子 DOM、瞬态弹出层里经常失灵，表现为「明明在输入框里，H 还在跳标题」。
怎么落地
- 真正要吃方向键或字符键的控件，使用对应的原生元素或补齐角色，并自己处理键盘；不要让阅读器误以为这是一段静态文档。
- 自定义下拉、选项卡、栅格，在焦点进入时要能把键交给控件，离开时还回去；不要依赖用户去记手动切换。
- 不要在浏览模式会征用的单键上绑定全局快捷键，除非提供关闭或冲突提示。
- 验证：打开 NVDA，先不碰模式开关，用 H、方向键走过正文，再 Tab 进每个表单控件打字。该跳标题时却打出字母，或该输入时却跳到了别处，就是模式归属错了。再用 JAWS 重复一次，确认自动切换不是某一家阅读器的巧合。