accesskey不能当快捷键用，因只移焦点不触发点击、不兼容多平台、移动端无效、易与浏览器快捷键冲突，且需显式标注才可用。
accesskey 为什么不能当“快捷键”用
它只负责把焦点移到元素上，不触发点击、不发 click 事件，也不拦截或转发键盘行为。用户按 Alt+S 后，按钮获得焦点，还得再按 Enter 或 Space 才能执行——这和“一键运行”完全不是一回事。
更麻烦的是：不同浏览器+系统组合下，触发方式完全不同。比如 accesskey="s" 在 Chrome/Windows 是 Alt+S，在 Firefox/macOS 却是 Ctrl+Option+Shift+S，而 Safari 默认压根不响应。用户根本没法记住，你也很难统一测试。
- 移动端完全忽略
accesskey（iOS Safari / Android Chrome 均不处理） - 屏幕阅读器（如 VoiceOver）通常绕过它，用自己的快捷键体系
- 浏览器默认快捷键会优先拦截：比如
accesskey="r"在 Chrome 中和“重新加载”冲突，按了没反应
哪些元素能用 accesskey，怎么写才有效
必须作用于可聚焦元素，否则静默失败。常见有效目标只有：button、a、input、textarea、select；div 或 span 加了 accesskey 也没用，除非显式加 tabindex="0"。
值只能是单个字符（字母、数字），不区分大小写，重复值会导致行为未定义。别用 accesskey="f"（Firefox 地址栏）、accesskey="t"（新标签页）这类已被占用的键。
立即学习“前端免费学习笔记（深入）”；
- ✅ 正确：
<button accesskey="s">保存</button> - ✅ 可聚焦容器：
<div accesskey="n" tabindex="0">新建项目</div> - ❌ 无效：
<span accesskey="h">帮助</span>（不可聚焦，无反应）
怎么让用户知道快捷键存在并降低误操作风险
accesskey 没有视觉反馈、不暴露在屏幕阅读器快捷键列表里，纯靠猜。必须在 UI 上显式标注，且标注方式要兼顾可访问性和可读性。
- 用
title属性提供悬浮提示：<button accesskey="r" title="Run code (Alt+R)">▶ Run</button> - 用
aria-label确保屏幕阅读器播报：<button accesskey="c" aria-label="Clear output (Alt+C)">清空</button> - 在按钮文字中直接写出快捷键：
<button accesskey="s">保存 (Alt+S)</button>—— 这是最可靠的方式，用户一眼可见 - 避免在输入框获得焦点时激活 accesskey：它会打断用户打字，且无法阻止
真正需要快捷操作时该怎么做
如果目标是“按 Ctrl+Enter 就运行代码”，accesskey 完全不合适。所有稳定可用的在线工具（CodeSandbox、StackBlitz、VS Code Web）都用 document.addEventListener('keydown') 实现。
- 监听
keydown（不是keypress，后者已废弃且不识别修饰键） - 用布尔属性判断组合键：
if (e.ctrlKey && e.key === 'Enter')，别依赖e.code（物理键位在非 QWERTY 布局下会错） - 先排除编辑态：
if (e.target.matches('input, textarea, [contenteditable]')) return - 调用
.focus()再.click()，确保屏幕阅读器能播报状态变化 - 给用户提供快捷键配置入口（如设置页），而不是硬编码在 HTML 里
accesskey 唯一合理的位置，是作为无障碍兜底入口——比如给“跳转到主内容”的 skip link 配 accesskey="s"，并确保它 focus 后按 Enter 能生效。但它不该承载核心交互逻辑，这点容易被忽略。
