accesskey不是提升网页操作效率的可靠手段，仅聚焦不触发点击，跨平台触发键混乱且移动端完全失效，实际需用keydown监听+preventdefault实现快捷操作。

accesskey 不是提升网页操作效率的可靠手段，它只负责把焦点移到元素上，不触发点击，且跨平台触发方式混乱、冲突多、移动端完全失效。

accesskey 的实际行为：只聚焦，不执行

给 <button accesskey="s">保存</button> 设置后，按对应组合键（如 Windows 下 Alt+S）只会让按钮获得焦点，不会自动点击。用户还得再按 Enter 或 Space 才能触发动作——这反而比直接 Tab 到按钮再按 Enter 多了一步。

• 所有主流浏览器都遵循这个“仅聚焦”逻辑，没有例外
• 无法用 CSS 或 JS 监听 “accesskey 被激活” 事件，keydown 也捕获不到它（因为浏览器在底层就截断了）
• 如果目标是“按快捷键就保存”，必须额外加 JS：监听 keydown 并手动调用 click()，但那就和 accesskey 无关了

不同系统+浏览器的触发键根本对不上号

你写 accesskey="s"，用户到底按什么？答案取决于六种组合：

• Chrome/Edge（Windows/Linux）：Alt+S
• Chrome（macOS）：Ctrl+Option+S（不是 Alt+S，Alt 键在 macOS 上常被系统占用）
• Firefox（Windows）：Alt+Shift+S（注意多一个 Shift）
• Firefox（macOS）：Ctrl+Option+S
• Safari（全平台）：忽略该属性，完全不响应
• 移动端（iOS Safari / Android Chrome）：全部静默忽略，无任何反馈

这意味着，你没法在帮助文档里写一句“按 Alt+S 即可”，因为对三分之一的用户来说，这句话就是错的。

Web Accessibility (WCAG 2 AA))

将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。

下载

为什么它经常“写了却没反应”？

常见静默失效场景，和代码是否正确无关：

• <div accesskey="n">新建</div>：无效，<div> 默认不可聚焦，必须加 <code>tabindex="0"
• Chrome 120+ 默认禁用键盘激活，只暴露给屏幕阅读器；需用户手动打开 chrome://flags/#enable-access-keys 并重启（普通用户不会做）
• 用了 accesskey="f"：Firefox 中会和“查找”（Ctrl+F）冲突，被浏览器直接拦截
• 页面有多个 accesskey="s"：行为未定义，有的浏览器聚焦第一个，有的跳过，有的报错

真正能落地的替代方案

如果目标是提升键盘操作效率，优先选这些可控、可测、可标注的方式：

• 对核心操作（如保存、提交、搜索），用 tabindex="0" + keydown 监听：document.addEventListener('keydown', e => { if (e.ctrlKey && e.key === 's') { save(); e.preventDefault(); } });
• 表单控件统一用 <label for="xxx"></label> 关联，配合自然 Tab 顺序，比记快捷键更符合用户直觉
• 高频入口（如顶部导航）提供 visible skip link：@#@#@#@#@#@#@#@#@#@0 —— 这里 accesskey 仅作辅助提示，核心依赖 href
• 复杂应用（如后台系统）直接参考 VS Code 做法：在设置页开放快捷键管理，允许用户自定义并实时生效

真正上线前，别只测 Chrome Windows。必须覆盖 Firefox macOS、Safari macOS、以及开启 VoiceOver/NVDA 的场景——accesskey 在这些环境里，要么行为异常，要么彻底消失。