键盘导航设计要同时解决“到哪里、看得见、做得了、回得去”。先为页面确定符合任务顺序的焦点路径，再补齐弹窗打开与关闭、列表更新、错误反馈后的落点。仅给按钮画一圈描边，不能保证用户不拿鼠标也能完成任务。
需要把弹窗规则做成可演示交互时，可对照墨刀弹窗与遮罩的制作步骤搭建覆盖层，再检查关闭、返回与焦点行为。
这件事既影响依赖键盘的用户，也影响表单录入、管理后台等高频操作。设计师需要交付行为规则，研发需要在真实页面验证；原型可以展示预期路径，但网页是否支持键盘，要看实际控件及其实现。
先分清焦点、选中和悬停
焦点表示当前接收键盘操作的位置；选中表示已经作出的选择；悬停表示指针停在某个对象上。它们可以同时出现，却不能共用一套含混的视觉状态。
| 状态 | 它在回答什么 | 界面中应该怎样表达 |
|---|---|---|
| 焦点 | 下一次键盘操作作用在哪里？ | 可见且持续的焦点样式，随导航移动 |
| 选中 | 当前选择或激活了哪一项？ | 勾选、当前标签或选中状态，焦点离开后仍保留 |
| 悬停 | 鼠标正在指向哪里？ | 辅助识别可操作区域，不承担唯一的功能入口 |
| 禁用 | 此时为什么不能操作？ | 可理解的状态和原因；不能只用变灰代替解释 |
例如采用手动激活模式的标签页，用户可以先把焦点移到另一标签，再按Enter或Space切换内容。此时已激活标签与焦点位置需要分别可辨；单选组等其他控件则应遵循各自的键盘模式。
页面导航顺序，从任务结构开始
先把页面拆成导航、筛选、结果和主要操作等区域。用户处理一组相关信息时，焦点应留在该组的逻辑路径中，避免在左右列之间反复跳跃。W3C 的焦点顺序说明强调保持含义与可操作性；顺序不必机械复制像素位置，但必须让人能理解。
- 列出用户可以操作的对象，例如输入框、链接、按钮和选择控件；装饰图标与普通段落通常不需要挨个进入 Tab 顺序。
- 从真实任务出发标注一条顺序：搜索条件 → 查询 → 结果中的操作 → 翻页。反向用 Shift＋Tab 也应能回到前一项。
- 展开筛选、出现错误或增加一条数据后，再检查路径。动态插入的内容不能让焦点突然回到页面顶部。
- 把复杂控件单独说明。标签页、菜单、树结构等可能有方向键导航模式，不要简单要求“内部每个对象都按一次 Tab”。
焦点顺序应与页面结构一起设计。若视觉上把内容完全重排，却只靠额外编号强行修补键盘顺序，后续响应式变化往往更难维护。交付时让研发检查实际结构与视觉排列是否相互支持。
弹窗要写清进入、内部移动和退出
以结果列表里的“编辑联系人”为例：用户激活某一行的编辑按钮，弹窗打开；完成修改或取消后，仍应能继续处理这个联系人。
| 阶段 | 建议规则 | 说明要具体到什么程度 |
|---|---|---|
| 打开 | 将焦点放入弹窗内合适的位置 | 短表单可落在首个字段；较长说明可先让用户读到标题与内容 |
| 内部导航 | Tab与Shift＋Tab在模态弹窗内部顺序移动 | 最后一个可操作项之后回到第一个，不落到被遮罩的列表 |
| 关闭 | 提供可发现的关闭或取消操作 | 常规模态弹窗支持Escape关闭；有未保存内容时明确丢弃或保留规则 |
| 返回 | 回到触发入口或下一处合理任务位置 | 原行仍存在则返回编辑按钮；原行消失时选择相邻结果或列表说明 |
这些行为依据WAI-ARIA模态弹窗模式。初始落点要服从内容和后果：不可逆操作不应默认把焦点放在最具破坏性的按钮上。弹窗内部可操作、背景不可操作，才是完整的模态行为。
列表变化后，焦点不要凭空消失
容易遗漏的情况不是正常打开弹窗，而是操作结束后原来的对象已经不在了。例如删除列表最后一行、筛选后当前记录被移出结果，或取消权限后编辑按钮消失。
- 删除一行后，优先让用户继续浏览相邻记录；如果列表变空，则落到能解释当前状态或创建新内容的位置。
- 重新查询时，不要无理由把焦点强制拉到远处结果。可以保留查询入口，并以合适方式告知结果数量；需要主动跳转的场景，应在设计中说明。
- 表单提交失败时，保留输入并让用户知道错误所在。错误较多可以提供汇总入口，关联到具体字段；不能只在视口外显示一行红字。
- 异步刷新不能反复抢回焦点。用户正在输入时，状态提示应告知变化，而不是打断输入。
这些落点应按任务设计，没有一条“全部回到第一个按钮”的通用答案。原型评审时，用一张包含“正常、被删除、结果为空”三种结果的路径图，比只画成功弹窗更容易发现遗漏。
焦点可见，还要不被浮层挡住
焦点框要在浅色、深色、选中和错误状态下都能辨认；不要为了界面干净就直接去掉默认焦点提示。固定导航、底部工具栏、Cookie提示和悬浮客服也可能遮住当前操作对象。
WCAG 2.2 的焦点不被遮挡最低要求关注获得焦点的控件不能被页面自身内容完全覆盖。实际设计可争取让整个控件与提示都可见，尤其需要在窄屏和页面放大后检查。
设计图里可增加两个视口状态：页面顶部固定栏存在、页面底部浮层存在。把焦点分别移到边缘位置，检查自动滚动后，用户是否仍能看清对象的名字与当前操作。
可复制的键盘交付说明
| 字段 | 编辑联系人弹窗示例 |
|---|---|
| 触发入口 | 结果列表中某行的“编辑”按钮 |
| 打开后的落点 | 姓名输入框；若存在需要先阅读的说明，改为说明区域 |
| 内部顺序 | 姓名 → 手机号 → 取消 → 保存 → 循环；若另有关闭按钮，也纳入实际Tab顺序。 |
| 关闭方式 | 取消、可见关闭按钮或Escape；存在修改时按约定处理未保存内容 |
| 完成后的落点 | 原行编辑按钮；原行不再可见时，返回结果区域的合理位置 |
| 错误处理 | 输入不丢失；错误靠近字段，用户可从错误汇总定位 |
| 验收方式 | 只使用键盘完成打开、编辑、纠错、取消和保存 |
可在墨刀原型中把这张说明放在对应弹窗和流程旁，用连线和编号展示预期，再与研发一起在实现版本验收。状态样式如何区分，可以结合视觉交互设计一起检查。
需要为高频动作增加命令入口时，再明确快捷键的作用范围和冲突规则，避免输入文字或打开弹窗时误触背景命令。
不拿鼠标，走完一次完整任务
- 刷新页面，用 Tab 找到目标入口，每次按键都能知道当前位置。
- 用键盘打开弹窗，正向和反向走遍控件，确认不会进入背景区域。
- 制造一处输入错误，检查能否找到、读懂并修正它。
- 取消再重新打开，检查焦点和已填内容是否符合规则。
- 完成操作后，继续处理下一项；再测试原对象消失及列表为空。
- 缩窄页面、放大内容并显示固定工具栏，确认焦点没有被挡住。
出现失败时记录页面、触发动作、实际落点和期望落点即可。把“键盘不好用”写成可复现的一条路径，设计和研发才能针对同一个问题修复。
