accesskey 仅触发焦点不执行操作，跨平台兼容性差且易被系统或插件拦截，实际可用性极低；可靠快捷键必须用 JavaScript 的 keydown 监听并严格判断上下文。
accesskey 不是快捷键方案，它只是个带副作用的焦点触发器——写对了也不保证可用，写错了反而破坏键盘导航。
accesskey 触发后只 focus，不 click，也不 submit
用户按 Alt+S（Windows）或 Ctrl+Option+S（macOS）后，浏览器只把焦点移到 <button accesskey="s"> 上，不会自动点击、不会提交表单、不会调用任何事件监听器。必须再按 Enter 或 Space 才能真正执行操作。
- 这意味着“保存(Ctrl+S)”这种语义在 accesskey 里根本不存在；
Ctrl+S会被浏览器原生拦截为“另存为”，accesskey="s"根本抢不到控制权 - 如果按钮绑定了
onclick或 React 的onClick，这些回调不会因 accesskey 被触发而运行 - 对
<input>或<textarea>设accesskey，只会让光标跳入，不会选中内容或触发focus以外的任何行为
不同平台组合键不统一，用户无法预期
同一段 HTML：<button accesskey="s">保存</button>，在真实环境中激活方式完全不同：
- Chrome/Windows：
Alt+S - Chrome/macOS：
Ctrl+Option+S（部分版本需加Shift） - Firefox/Windows：
Alt+Shift+S - Safari/macOS：默认关闭，开启后是
Ctrl+Option+S，但 VoiceOver 启用时可能重映射为Control+Option+1 - iOS/Android：全部忽略，无 fallback
你写在 UI 上的提示 “(Alt+S)” 对 macOS 用户就是错的，而改成 “(Ctrl+Option+S)” 又会让 Windows 用户困惑——没有一种标注能覆盖所有路径。
Accessibility Review
下载
对设计或页面进行 WCAG 2.1 AA 无障碍审计。触发关键词：“audit accessibility”、 “check a11y”、 “is this accessible?” 或在审查设计时使用。
立即学习“前端免费学习笔记（深入）”；
硬拦截远多于代码错误，“无效”基本不是你写的锅
绝大多数 “写了没反应” 的 case，根源不在 HTML 语法，而在环境层被静默吞掉：
- macOS 系统级快捷键（如
Cmd+Space唤起 Spotlight、Cmd+Shift+5截图）会直接劫持组合键，浏览器收不到 - 密码管理器、Vim 风格扩展（如 Vimium）、审计插件监听所有
keydown并preventDefault()，accesskey 失效且无报错 - 焦点落在
<textarea>或contenteditable区域时，accesskey 逻辑完全不触发 - Chrome 120+ 默认禁用键盘激活，仅通过可访问性 API 暴露，普通用户无感知；需手动打开
chrome://flags/#enable-access-keys并重启
真要支持快捷键，得绕开 accesskey 写 JavaScript
稳定可控的快捷键必须走 document.addEventListener('keydown')，并做严格上下文判断：
- 用
e.code（如'KeyS'）而非e.key，避免输入法、CapsLock、IME 干扰 - 过滤编辑态：
if (e.target.matches('input, textarea, [contenteditable]')) return - 修饰键判断要精确：
e.ctrlKey && e.shiftKey && e.code === 'KeyF'，不能只靠e.key === 'f' - 全局监听需配合
document.hasFocus()，防止多标签页误触发 - 若需兼容 macOS 的 Cmd 键，统一用
e.metaKey，但注意 Windows 用户习惯 Ctrl，别强求“跨平台一致”
accesskey 唯一还剩点价值的场景，是给搜索框、主菜单、跳至主内容这类极少数高频跳转加一个降级提示——但前提是已用 JS 实现了可靠监听，且 UI 上明确标注了组合键差异。
