accesskey不是快捷键功能实现方案，它只负责把焦点移到元素上；按了没反应、不触发点击、移动端完全无效——这些不是bug，而是它的设计本质。
accesskey 不是快捷键功能实现方案，它只负责把焦点移到元素上；按了没反应、不触发点击、移动端完全无效——这些不是 bug，而是它的设计本质。
accesskey 的实际行为：聚焦 ≠ 激活
给 <button accesskey="s">保存</button> 加了属性后，用户需按平台组合键（Windows/Linux 是 Alt+s，macOS 是 Ctrl+Option+s），结果只是让按钮获得焦点，不会自动点击。要真正执行保存，还得再按 Enter 或 Space。
- 它不改变元素语义，
accesskey不会让<div>变成可交互元素——必须加tabindex="0"才能响应 - 值必须是单字符：
accesskey="1"合法，accesskey="ctrl+s"、accesskey=" "、accesskey="?"全部被忽略 - 大小写不敏感：
accesskey="S"和accesskey="s"效果一致 - 重复值会导致行为不可预测：同一页面多个
accesskey="s"，Firefox 聚焦第一个，Chrome 可能跳过
为什么你写的 accesskey 经常“按不出来”
不是代码错了，是环境限制太强：
- Chrome 120+ 默认禁用键盘激活，
accesskey仅暴露于可访问性 API，不响应物理按键 - Firefox 中
accesskey="f"与「查找」(Ctrl+F) 冲突，直接被拦截 - Safari（所有平台）默认忽略
accesskey，即使开启「使用键盘快捷键导航」也只对链接和按钮有限支持 - 移动端完全不支持：iOS Safari / Android Chrome 均静默跳过，虚拟键盘无
Alt上下文 - 屏幕阅读器（如 VoiceOver）可能重映射
accesskey，比如把accesskey="h"当作「跳到标题」，你的按钮收不到事件
哪些地方还能勉强用，怎么降低风险
如果非要用（例如内部管理后台满足 WCAG 2.1 Level A 的极小范围场景），只限以下条件：
立即学习“前端免费学习笔记（深入）”；
- 只绑定到天然可聚焦元素：
<button>、<a href>、<input>；若用在容器上，必须显式加tabindex="0" - 避开高冲突键位：不用
accesskey="w"（窗口管理）、"n"（新建标签）、"r"（刷新）、"f"（查找）、"s"（保存页面） - 优先选数字或冷门字母：
accesskey="7"、accesskey="q"、accesskey="z"，冲突概率更低 - 必须显式标注提示：
<button accesskey="7">导出(Alt+7)</button>，否则用户根本不知道存在这个快捷方式 - 配合
aria-label或title，因为accesskey本身不向辅助技术传递额外语义
真正需要快捷操作时，该怎么做
别依赖 accesskey 实现功能，它只是个辅助导航入口。可靠路径是：
- 用
document.addEventListener('keydown', handler)监听全局事件，判断e.ctrlKey && e.key === 's'（注意用e.key，不是e.code，避免 AZERTY 键盘错判） - 先排除输入状态：
if (['INPUT', 'TEXTAREA', 'SELECT'].includes(e.target.tagName) || e.target.isContentEditable) return - 对关键操作做
e.preventDefault()，但只针对你明确注册的组合键，别拦Ctrl+T这类系统级行为 - 触发前主动
.focus()目标元素，再.click()，确保屏幕阅读器能播报状态变化 - Mac 用户用
e.metaKey，Windows/Linux 用e.ctrlKey，别混用或硬写 “Ctrl” 文字
最常被忽略的一点：快捷键的可靠性不取决于你写了几个 accesskey，而取决于是否建立了可预测的焦点流、是否对键盘事件做了防冲突过滤、以及是否在视觉上同步反馈当前操作目标。
