accesskey仅将焦点移至元素，不触发操作，现代浏览器支持差且不可靠，需用keydown监听实现真正快捷键。
accesskey 不是快捷键绑定机制，它只负责把焦点移到元素上，不触发任何操作，也不保证用户能发现或稳定使用。 它在现代网页中基本不可靠，仅适合极小范围的 WCAG 合规补位，不能替代真正的键盘交互逻辑。
accesskey 触发后到底发生了什么？
它只做一件事：把键盘焦点移到目标元素。不会调用 click()，不会触发 submit，也不会执行任何自定义逻辑。用户按完组合键后，还得再按 Enter 或 Space 才可能完成操作——这和“快捷键”的直觉完全不符。
- Chrome/Windows 下按
Alt+s→ 按钮获得焦点，但无其他反应 - Safari/macOS 默认忽略，除非用户手动开启「辅助功能→在网页中使用键盘快捷键」
- Firefox 有时需先按
Alt激活菜单栏，再按对应键，路径断裂 - 所有移动端浏览器（iOS Safari、Android Chrome）静默跳过，无例外
哪些元素能响应 accesskey？
只有原生可聚焦元素才有效。非交互语义标签加了也白加，浏览器直接忽略。
- ✅ 有效：
button、a、input、textarea、select - ✅ 可聚焦容器：
div或span加tabindex="0"后可响应 - ❌ 无效：
table、tr、td、div（无tabindex）、span（无tabindex） - ⚠️ 注意：
div加了tabindex="0"后虽能聚焦，但屏幕阅读器不一定播报其作用，需配role和aria-label
为什么用户按了没反应？常见失效链
不是代码写错，而是整个链路被环境截断。从触发到反馈，每一环都可能失败。
- 浏览器已禁用：Chrome 120+ 默认关闭键盘激活，仅通过可访问性 API 暴露（普通用户根本感知不到）
- 系统快捷键抢占：
Alt+Tab、Cmd+Space、Ctrl+T等会直接吞掉组合键 - 扩展劫持：密码管理器、翻译插件常监听
Alt或Ctrl组合，优先拦截 - 焦点不在页面主体：弹窗遮挡、
iframe内容未获焦点、页面刚加载完尚未 ready，都会导致静默失败 - 值冲突或非法：
accesskey="ctrl+s"（必须单字符）、accesskey=" "（空格）、accesskey="?"（非 ASCII）全被忽略
真正需要快捷操作时该怎么做？
用 document.addEventListener('keydown') 监听，但必须处理上下文。这是唯一可控路径。
- 判断组合键用布尔属性：
e.ctrlKey && e.key === 's'，别用e.code（AZERTY/Dvorak 键盘下错位） - Mac 用户用
e.metaKey，Windows/Linux 用e.ctrlKey，别混写成 “Ctrl+S” 文字提示 - 先排除输入场景：
if (['INPUT', 'TEXTAREA', 'SELECT'].includes(e.target.tagName) || e.target.isContentEditable) return - 触发前先
.focus()目标元素，再.click()，确保屏幕阅读器播报且支持后续Enter/Space - 显式标注快捷键：
保存 (<code>Ctrl+S)，而不是指望用户发现accesskey
最常被忽略的一点：快捷键是否“可用”，不取决于你有没有写 accesskey，而取决于焦点流是否清晰、输入拦截是否严谨、视觉反馈是否同步——这些才是真实影响用户操作的环节。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
