accesskey 不是可靠、可预期的键盘导航方案，仅适用于极简静态页的辅助跳转，需显式标注并跨浏览器测试；其触发组合键因浏览器和系统而异，易与默认快捷键冲突，且常因环境或语义问题失效；更可控的替代方案是用 JavaScript 监听 keydown 自定义组合键逻辑。
accesskey 不是可靠、可预期的键盘导航方案，尤其在现代 Web 应用中。它仅适合极简静态页的辅助跳转，且必须配合显式标注和跨浏览器测试，否则多数用户根本不知道它存在，或按了没反应。
accesskey 在不同浏览器里到底怎么触发
没有统一组合键——这是最常被忽略的前提。你写 accesskey="s"，但用户按下什么才能生效，完全取决于浏览器+系统：
- Chrome（Windows/Linux）：
Alt+S；macOS：Ctrl+Option+S - Firefox（Windows/Linux）：
Alt+Shift+S；macOS：Ctrl+Option+S - Edge：同 Chrome（Windows），
Ctrl+Option+S（macOS） - Safari：默认禁用，需手动开启「偏好设置 → 辅助功能 → 使用键盘快捷键导航」，之后才支持
Alt+S（Windows）或Ctrl+Option+S（macOS） - Opera（新版）：
Alt+S；旧版需Shift+Esc呼出列表
这意味着：同一段 HTML，在用户电脑上可能完全失效，或触发浏览器保存页面（Alt+S 和 Ctrl+S 冲突）、打开搜索栏等系统行为。
为什么 accesskey 经常“按了没反应”
常见失效原因不是代码写错，而是环境或语义问题：
-
accesskey值不是单字符（如写了accesskey="save"）→ 浏览器直接忽略 - 目标元素不可聚焦（比如
div没加tabindex="0"，或被display: none/visibility: hidden隐藏） - 多个元素用了同一个
accesskey值（如两个按钮都设accesskey="s"）→ 行为未定义，各浏览器随机选一个或全不响应 - 用户正在输入框内打字，焦点在表单控件上 → 多数浏览器会跳过
accesskey触发（除非该控件本身设置了该 key） - 屏幕阅读器已接管键盘事件（如 NVDA、VoiceOver）→ 可能屏蔽或重映射
accesskey，不按你写的逻辑走
比 accesskey 更可控的替代做法
真要实现键盘导航增强，优先用 JavaScript 监听 keydown，自己掌控组合键逻辑：
- 用
e.ctrlKey && e.key === 'k'判断Ctrl+K，比依赖浏览器玄学触发更稳定 - 加
e.preventDefault()阻止浏览器默认行为（如Ctrl+S保存页面） - 给需要接收焦点的非交互元素（如
td、div）加上tabindex="0"，再调用.focus() - 用
when条件控制作用域（例如只在编辑器区域响应Ctrl+Enter提交） - 在 UI 上显式提示：“搜索（
Ctrl+K）”，而不是靠用户猜或查文档
示例：为搜索框绑定 Ctrl+K 并自动聚焦
document.addEventListener('keydown', (e) => {
if (e.ctrlKey && e.key === 'k') {
e.preventDefault();
document.getElementById('search-input').focus();
}
});
如果非用 accesskey，这些细节不能漏
仅限核心跳转场景（如“跳至主内容”、“返回顶部”、“打开菜单”），且必须满足：
- 值限定为 ASCII 单字符（
a-z、0-9、-、.等，避免空格或中文） - 每个页面唯一，不与浏览器默认快捷键冲突（避开
F1、F5、s、r、t等高频键） - HTML 中显式标注，例如：
<button accesskey="h">首页（Alt+H）</button> - 在无障碍测试时，同时用 Chrome + NVDA、Safari + VoiceOver 实测是否真能聚焦，而不是只看桌面浏览器表现
真正难的从来不是加个属性，而是让不同设备、不同辅助技术、不同操作习惯的人，都能一致、可预期地触发同一行为——accesskey 天然做不到这点，别把它当主力方案。
