accesskey不是提升键盘导航体验的秘诀，它只是有严重限制的原生焦点跳转机制，实际项目中基本不可靠，不建议作为键盘导航方案使用。

accesskey 不是提升键盘导航体验的“秘诀”，它只是个有严重限制的原生焦点跳转机制，实际项目中基本不可靠，不建议作为键盘导航方案使用。

为什么 accesskey 无法稳定提升键盘导航体验

它只做一件事：按下组合键后让目标元素获得焦点（focus()），不触发点击、不滚动到可视区、不提供视觉反馈，且行为完全不受控：

• 不同浏览器激活方式差异极大：Chrome/Windows 是 Alt+S，Firefox/macOS 是 Ctrl+Alt+S，Safari 默认甚至不响应
• 焦点跳过去后，<input> 光标不一定在末尾，用户仍需手动按 End 或鼠标点选
• 没有统一方式提示用户“这个按钮支持快捷键”，accesskey="s" 对用户完全不可见
• 与系统级快捷键硬冲突：比如 Alt+F4 关窗、Ctrl+T 开新标签，一按就中断操作
• 屏幕阅读器（如 VoiceOver、NVDA）可能忽略、重映射或意外激活，反而破坏无障碍流

accesskey 在哪些场景下连“能用”都难保证

即使你写了 <button accesskey="s">保存</button>，以下情况它大概率失效：

• 用户正在 <textarea></textarea> 中输入中文，按下 Ctrl+S —— 浏览器直接弹出“另存为”对话框
• macOS 用户没在「系统设置 → 键盘 → 快捷键」里关闭「用键盘控制」的全局拦截
• 页面同时存在多个 accesskey="s"，浏览器行为未定义，有的忽略，有的随机选一个
• 用户用的是 Chrome 扩展（如 Vimium、SurfingKeys），它们会劫持所有 keydown 事件，accesskey 彻底被屏蔽

真正可控的键盘导航替代方案

要实现可靠、可维护、符合 WCAG 的键盘导航，必须绕过 accesskey，改用 JavaScript 监听 document 级事件：

htmlppt.skill

把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。

下载

• 监听 keydown 时，同时检查 e.ctrlKey 和 e.metaKey，避免 macOS 下 Cmd+S 失效
• 优先用 e.code === 'KeyS' 判断物理按键，而非 e.key === 's'（后者受 CapsLock、输入法干扰）
• 在 <input>、<textarea></textarea>、contenteditable 内自动跳过快捷键逻辑，防止打断输入
• 必须在组件卸载时移除监听器（React 用 useEffect 清理函数，Vue 用 onUnmounted），否则内存泄漏
• 快捷键组合必须显式标注在 UI 上，例如：保存 (Ctrl+S)，并保持全站一致

如果非要用 accesskey，至少避开这些坑

极少数合规审计强制要求时，可保留但需严格约束：

立即学习“前端免费学习笔记（深入）”；

• 仅用于高频核心操作：搜索框（accesskey="s"）、主菜单（accesskey="m"）、跳转到主内容（accesskey="0"）
• 绝对避开 F1–F12、Tab、Esc、Enter 等系统保留键
• 值必须是单字符，且全站唯一；避免用 1、2 这类数字——某些键盘布局下无法直接输入
• 必须配合 visible 文本标注，例如：搜索 <span aria-label="快捷键：Alt+S">(Alt+S)</span>

真正的键盘导航体验取决于 tab 顺序合理性、focus 样式可见性、skip link 是否存在，而不是某个属性是否“写上了”。accesskey 的最大陷阱，就是让人误以为加了它就算做了无障碍。