accesskey 无效主因是系统/浏览器/扩展硬拦截，而非代码错误；它仅触发 focus 而非 click 或提交，且无视觉反馈、不可监听、跨平台组合键不统一，实际应慎用。

accesskey 按了没反应？先查这三类硬拦截

绝大多数“写了却无效”的 case，根本不是代码写错，而是被系统、浏览器或扩展直接吃掉了。Chrome/macOS 下 Alt+Shift+S 很可能被系统「截图」快捷键劫持；Firefox 中若启用了 accessibility.typeaheadfind，Alt+S 会直接触发页面内搜索而非聚焦元素；Safari 17 仍默认忽略 accesskey，除非用户手动在「偏好设置 → 辅助功能 → 使用键盘快捷键访问网页项目」里打开开关。

常见拦截点包括：

• macOS 系统级快捷键（如 Cmd+H 隐藏窗口、Cmd+Space 唤起 Spotlight）
• 密码管理器、翻译插件、Vim 风格扩展（如 Vimium）监听所有 keydown 事件并阻止冒泡
• 焦点落在 <textarea></textarea> 或 contenteditable 区域时，accesskey 逻辑完全不触发

为什么你不能靠 accesskey 实现“保存(Ctrl+S)”语义

accesskey 只做一件事：让目标元素获得焦点（focus()），它不调用 click()，不提交表单，不执行任何回调。即使你写的是 <button accesskey="s">保存</button>，用户按下组合键后只是把焦点移到按钮上——还得再按一次 Enter 或 Space 才真正触发点击。

更现实的问题是：

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

• Ctrl+S 在所有主流浏览器中都会触发“另存为”原生行为，accesskey="s" 根本抢不到控制权
• 没有视觉反馈机制，无法用 CSS 选中“当前被 accesskey 激活的元素”，用户完全感知不到发生了什么
• 无法监听 accesskey 被触发的事件，也没有类似 onaccesskey 的钩子

跨浏览器触发组合键混乱到无法统一文档

同一个 accesskey="s"，在不同环境下的激活方式如下：

• Chrome/Windows：Alt+S
• Chrome/macOS：Alt+Option+S（部分版本需加 Shift）
• Firefox/Windows：Alt+Shift+S
• Firefox/macOS：Ctrl+Option+S
• Safari/macOS：默认关闭，开启后是 Ctrl+Option+S，但 VoiceOver 启用时可能重映射
• iOS/Android：全部无视 accesskey 属性

这意味着你写在 UI 上的提示“保存(Alt+S)”对 macOS 用户就是错的，而写成“保存(Ctrl+Option+S)”又会让 Windows 用户困惑。没有一种写法能覆盖所有真实用户路径。

真正上线前必须验证的三个不可绕过环节

如果合规审计强制要求保留 accesskey，至少确保它不拖累可用性：

• 只用于极少数高频核心跳转：搜索框（accesskey="s"）、主菜单（accesskey="m"）、跳至主内容（accesskey="0"），避开 F1–F12、Tab、Esc 等系统保留键
• 每个 accesskey 值全站唯一，重复值会导致浏览器行为未定义（Chrome 可能激活第一个，Firefox 可能随机选）
• 必须在 UI 上显式标注，例如按钮旁加小字“（Alt+S）”，且该标注要随用户操作系统动态切换（检测 navigator.platform 切换提示文案）

实际项目中，accesskey 的存在本身就会增加测试成本和维护负担——它既不能替代 JavaScript 快捷键，也不能满足 WCAG 对可发现性与一致性的要求。真要落地快捷键，document.addEventListener('keydown') 是唯一可控入口，而 accesskey 最多只能当个弱提示补充，别让它承担任何关键路径。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！