鼠标用户有光标告诉自己将点击哪里，键盘用户靠焦点指示器完成同样定位。把默认 outline 去掉却没有替代方案，相当于把光标隐藏。Focus 的视觉不一定是浏览器蓝框，但必须持续、清楚、可预测。
01 WCAG 2.2 要求键盘操作时焦点可见
W3C 的 Focus Visible 成功标准要求任何可键盘操作界面在键盘焦点状态下有可见指示。
“outline: none”本身不是绝对错误，前提是你提供了同样或更清楚的替代焦点样式。现实中很多项目只做了前半句。
02 Focus 和 Hover 不能共用到完全一样
Hover 只在鼠标经过时出现，Focus 可能来自 Tab、快捷键或程序导航。
两者可以视觉相关，但 Focus 必须足够稳定和明显，不能鼠标移开就消失。
03 Tab 顺序应该跟视觉与任务顺序一致
使用 CSS 视觉重排却保留 DOM 完全不同顺序，会让键盘焦点在页面上乱跳。
避免滥用正 tabindex。更好的方式是让 DOM 本身按阅读顺序组织，再用布局系统表达视觉。
04 Modal 打开时要把焦点带进去，并避免跑到背后页面
键盘用户打开对话框后，如果继续 Tab 进入被遮住的页面内容，会失去上下文。常见做法是 Focus Trap，并在关闭后将焦点返回触发按钮。
这需要开发实现，但设计稿应说明初始焦点位置、关闭方式和键盘行为。
05 长页面需要 Skip Link 帮助跳过重复导航
键盘用户每次打开新页面都要 Tab 20 次才能越过 Header，是明显负担。
“Skip to main content”可以在获得焦点时显示，让用户直接进入正文。它通常不会干扰鼠标视觉。
06 :focus-visible 可以避免鼠标点击后出现不必要焦点样式
现代浏览器支持 focus-visible 伪类，根据输入方式更智能地展示焦点。
这样可以同时满足设计审美和键盘可用性，不必用“鼠标用户不喜欢蓝框”作为删除焦点的理由。
07 SPA 路由和动态内容需要主动管理焦点
传统页面跳转会重新加载，单页应用改变内容后焦点可能仍停留在已经消失的按钮。
关键视图切换应决定焦点去向，例如移动到新页面标题或主要容器，并给屏幕阅读器明确上下文。
08 最简单的 QA 方法：把鼠标放下，只用键盘完成任务
从登录、导航、筛选、打开 Modal、提交表单到关闭提示，全程只用 Tab、Shift+Tab、Enter、Space、Esc。
如果设计师自己都不知道焦点现在在哪，用户当然也不会知道。键盘测试应该进入设计验收常规流程。
09 焦点样式应该成为组件状态，而不是开发最后统一补 CSS
Button、Link、Input、Tab、Menu Item 的 Focus 外观需要与组件形状和背景匹配。一个全站统一的外发光在浅色按钮上可能清楚，在品牌色卡片上却完全看不见。
设计系统可以定义 Focus Ring 的宽度、间距、颜色和高对比替代方案，让开发不用为每个控件临时猜。
10 键盘体验还包括关闭、返回与错误后的焦点恢复
提交表单失败后如果只在页面顶部出现红字，键盘用户可能不知道发生了什么；关闭弹窗后焦点跳回页面开头，也会打断任务。
因此 Focus 管理要和状态反馈一起设计：错误时定位到错误摘要或首个问题字段，完成临时任务后返回原触发位置。
常见问题
可以去掉浏览器默认蓝色 Outline 吗？
可以，但必须提供清晰可见的替代 Focus 样式。
Focus 和 Hover 可以一样吗？
可以有相似视觉，但 Focus 必须在键盘操作中持续可见，不应依赖鼠标。
Tabindex=1、2、3 可以控制顺序吗？
技术上可以，但通常不建议依赖正 tabindex，优先让 DOM 顺序本身合理。
Modal 为什么需要 Focus Trap？
防止键盘焦点进入被遮挡的背景内容，并保持对话任务上下文。
Skip Link 会影响视觉吗？
可以默认隐藏，在键盘获得焦点时显示，因此不会明显干扰普通视觉布局。
相关服务与进一步咨询
链接复制成功
