HTML中不存在真正可用的快捷键功能，accesskey仅为语义标记，其触发依赖浏览器与系统策略，Chrome用Alt+key（Win）或Ctrl+Alt+key（macOS），Safari已默认禁用，且不支持多字符或重复值。
HTML快捷键根本不存在，浏览器不解析accesskey的常见原因
HTML里没有“快捷键”这个运行时功能，accesskey属性只是语义标记，是否触发、怎么触发完全取决于浏览器和操作系统的组合策略。Chrome在Windows上默认用Alt+accesskey，macOS上却是Ctrl+Alt+accesskey，而Safari近年已默认禁用accesskey响应——不是你的代码错了，是它压根没被设计成可靠交互手段。
-
accesskey值必须是单字符（a、1、-），多字符如"save"会被忽略 - 若页面有多个相同
accesskey（比如两个accesskey="s"），多数浏览器只激活第一个，且不报错 - 屏幕阅读器可能绕过
accesskey直接走ARIA导航流，实际用户根本不会按它
真正可用的键盘操作：用tabindex和keydown接管焦点与响应
想让元素支持键盘访问和操作，核心不是加accesskey，而是确保它可聚焦、可监听、行为可预测。按钮、链接天然可聚焦；div或span必须加tabindex="0"才能进Tab顺序，再用keydown监听Enter或Space。
- 避免
tabindex="-1"后手动.focus()再监听——这会打断用户自然Tab流，尤其对盲人用户不友好 - 监听
keydown时务必检查e.key而非e.keyCode（已废弃），比如e.key === "Enter"比e.keyCode === 13更可靠 - 自定义控件（如手写的下拉菜单）必须用
role+aria-*声明状态，否则键盘用户无法感知展开/收起
button.addEventListener("keydown", e => {
if (e.key === "Enter" || e.key === " ") {
e.preventDefault(); // 防止空格触发滚动
handleClick();
}
});兼容性陷阱：Mac Safari和Firefox对accesskey的静默失效
即使你写了<button accesskey="s">保存</button>，在macOS Safari 16+和Firefox中按下Ctrl+Alt+s大概率毫无反应。这不是bug，是厂商主动限制——因为accesskey极易与系统快捷键冲突（比如Cmd+S是保存网页），且历史上被滥用为“隐藏入口”，影响可访问性。
- Chrome Canary曾短暂支持
accesskey高亮提示（悬停显示小标签），但正式版已移除 - Edge基于Chromium后行为与Chrome一致，但企业策略组可能通过
accessibility.accesskey策略强制关闭 - 唯一能验证
accesskey是否生效的方法是打开开发者工具，在Elements面板里右键元素 →Scroll into view，然后手动按快捷键观察焦点变化
替代方案：用aria-keyshortcuts声明意图，不依赖执行
WAI-ARIA 1.2引入了aria-keyshortcuts，它不触发行为，只告诉辅助技术“这个按钮通常用Ctrl+S触发”。这对屏幕阅读器用户有用（读出“快捷键 Ctrl+S”），但不会让浏览器自动绑定事件。真要实现，还得自己写keydown监听逻辑，并保持两者严格一致。
立即学习“前端免费学习笔记（深入）”；
- 值必须是空格分隔的字符串，如
aria-keyshortcuts="Ctrl+S Ctrl+Shift+S"，不能写cmd+s（大小写敏感） - 不要和
accesskey混用——同一元素同时设两者，辅助技术可能混淆优先级 - 如果业务强依赖快捷键（如编辑器），直接监听
window级keydown并做event.target判断，比依赖元素属性更可控
真正难的从来不是加个属性，而是保证键盘路径从进入页面到完成操作全程无断点——焦点不丢失、状态可感知、反馈及时。很多团队卡在“以为加了accesskey就完成了键盘支持”，结果连Tab都不能走到关键按钮。
