accesskey仅用于聚焦元素，不触发操作；实现ctrl+s等快捷功能须用keydown监听。常见失效因浏览器拦截、键值错误或绑定非聚焦元素，正确做法是监听keydown并判断组合键与上下文。
accesskey 不是用来“自定义网页快捷键”的，它只负责把焦点移到元素上，不触发任何操作。真要实现 Ctrl+S 保存、/ 打开帮助这类行为，必须用 keydown 监听——accesskey 是辅助导航机制，不是功能触发开关。
为什么 accesskey 按了没反应
常见错误现象：加了 accesskey="s"，按 Alt+S 却没跳转、没弹窗、也没执行保存逻辑。
- 它本就不该触发点击：
accesskey的规范目标是“聚焦”，不是“激活”。焦点落到按钮上后，用户还得再按 Enter 或 Space 才能触发 click - 浏览器拦截严重：Chrome 中 Alt+S 默认跳地址栏，Firefox 中 Alt+Shift+S 可能被扩展劫持，Safari 默认禁用且需手动开启「在网页中使用键盘快捷键」
- macOS + VoiceOver 下，
accesskey="h"会被直接当成“跳到标题”命令，你的按钮完全收不到事件 - 值写错就会静默失效：比如
accesskey="ctrl+s"（必须是单字符）、accesskey=" "（空格）、accesskey="?"（非 ASCII）都会被忽略
如何让 accesskey 至少能聚焦成功
如果仍想保留 accesskey 作为辅助导航入口（例如给“跳至主内容”链接），这些实操建议能提升基础可用性：
- 绑定到语义化可聚焦元素：
@#@#@#@#@#@#@#@#@#@0或<button>保存</button>，别绑<div>（除非加 <code>tabindex="0"） - 确保视觉可感知：检查
:focus样式是否被重置或覆盖，焦点样式必须明显（如带 outline 或背景色） - 避免冲突键位：避开
accesskey="w"（Chrome 窗口管理）、"n"（新建标签）、"r"（刷新）等易被系统占用的字母 - 多个相同值时行为未标准化：Firefox 聚焦第一个，Chrome 可能跳过，所以务必保证全站唯一
- 用布尔属性判断组合键：
if (e.ctrlKey && e.key === 's')，别用e.code === 'KeyS'（AZERTY 键盘下会错） - 先排除输入场景：
if (['INPUT', 'TEXTAREA', 'SELECT'].includes(e.target.tagName) || e.target.isContentEditable) return - 只对明确注册的快捷键调
e.preventDefault()，比如 Ctrl+T 就不该拦——拦了也无效，还破坏体验 - 触发操作前先
.focus()目标元素，再.click()，这样屏幕阅读器能播报状态变化，也兼容后续 Enter/Space 操作 - Mac 用户用
e.metaKey，Windows/Linux 用e.ctrlKey，别混用或硬写Ctrl文字 - 必须用
<dialog id="shortcut-panel"></dialog>，打开时调dialog.showModal()，关闭时显式调dialog.close() - 结构用
<dl> <dt> <kbd>Ctrl</kbd>+<kbd>K</kbd> </dt> <dd>聚焦到全局搜索框</dd> </dl>，语义清晰、CSS 易控、读屏友好 - 动态替换 Cmd 图标：
if (navigator.platform.includes('Mac')) kbdEl.textContent = '⌘'，别写两套 HTML - 最常踩的坑：按下 Ctrl+/ 后面板一闪就关——检查是否在快捷键处理函数里误写了
dialog.close()，或有其他监听器无条件监听 click 并关闭 dialog
真正可用的快捷键必须用 keydown 实现
监听 document 上的 keydown，才能绕过 accesskey 的平台限制和语义局限：
快捷键面板要用 dialog 元素
按 ? 显示快捷键列表时，别用 div + display: none，否则焦点管理崩坏、无障碍语义丢失：
真正难的不是监听按键，而是判断「此刻该不该响应」：光标在输入框里？用户刚点了右键？系统已劫持这个组合？这些边界情况不处理，快捷键就会在关键时候失灵。
