accesskey触发后没反应，大概率是被浏览器或系统静默拦截，因其仅聚焦不触发事件；应弃用并改用document.addeventlistener('keydown')监听，配合e.code判断、修饰键检查及编辑态跳过。

accesskey 触发后没反应，大概率是被浏览器或系统吞了

不是你代码写错了，而是 accesskey 本身不参与事件流，只负责把焦点移到元素上——它不发 click，也不触发 keydown，更不会绕过浏览器菜单键（比如 accesskey="f" 在 Firefox 中直接跳到地址栏）。Windows 下按 Alt+f、macOS 下按 Ctrl+Option+f，这些组合早被系统/浏览器预占，静默拦截，无提示、无日志。

常见失效场景包括：

• accesskey="s" 在 Chrome Windows 下可能激活地址栏而非你的按钮
• accesskey="r" 在 Safari macOS 上默认完全忽略，除非用户手动开启「辅助功能 → 使用键盘快捷键导航」
• 企业环境里，1Password、Okta 插件会全局监听 Alt+x 类组合并调用 e.preventDefault()，你的页面收不到任何信号

别修 accesskey，直接换掉它：用 document.addEventListener('keydown')

所有稳定项目（CodeSandbox、GitHub Codespaces、VS Code Web）都已弃用 accesskey 做快捷键路由。真正可控的方案是监听 document 级 keydown，但必须满足三个硬约束：

html-to-pptx-converter

使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。

下载

• 用 e.code 判断按键，比如 e.code === 'KeyR'；别用 e.key，后者在中文输入法下常为空或大小写错乱
• 显式检查修饰键：e.ctrlKey && e.shiftKey，避开 Alt 系列（Windows 菜单键、macOS 输入法切换键）
• 动态跳过编辑态：if (document.activeElement.matches('input, textarea, [contenteditable]')) return，防止用户写注释时误触运行

如果必须保留 accesskey，只当它是个无障碍兜底入口

accesskey 不该承载核心操作逻辑，只适合给高频、低风险动作配一个可访问性入口，例如「清空输出」或「跳转帮助」。要让它不翻车，得严格守这几条：

• 值必须是单个 ASCII 字符（a–z、0–9、-、=），accesskey="ctrl+s" 这种写法会被浏览器静默忽略
• 绑定对象必须可聚焦：<button></button> 可以，<div> 必须加 <code>tabindex="0"，<span></span> 加了也没用
• 避免与 MDN 列出的 reserved access keys 冲突，比如 f（查找）、t（新标签页）、w（关闭窗口）
• UI 上必须显式标注，例如：<button accesskey="c">清除(Alt+C)</button>；否则用户根本不知道这个键存在

测试 accesskey 是否真生效，不能只靠自己点一点

它是否起作用，取决于目标用户的实际环境，不是开发机配好了就行：

• 在无痕模式下测试，禁用所有插件（尤其密码管理器和翻译工具）
• 换系统：Windows 试 Alt+s，macOS 试 Ctrl+Option+s，注意 VoiceOver 可能劫持 h（跳标题）、l（跳链接）
• 用控制台实时验证：document.activeElement 是否等于你的目标元素；如果没变，说明组合键压根没落到页面
• 别信「支持列表」——Chrome 120+ 默认禁用键盘激活，需手动打开 chrome://flags/#enable-access-keys 并重启

真正难的不是写监听，而是让快捷键在富文本编辑、模态框弹出、多 tab 切换、输入法激活等真实场景下不误触发、不丢失上下文。这些细节不处理，accesskey 或 JS 监听都会变成不可维护的定时炸弹。