accesskey 不是可靠快捷键方案，chrome 120+ 和 safari 全平台默认失效或完全忽略，触发组合键因浏览器和系统差异极大，且受元素可聚焦性、重复值、输入框焦点等多重限制；推荐用 javascript 监听 keydown 自行实现。
accesskey 不是可靠快捷键方案，设了也大概率不生效，尤其在 Chrome 120+ 和 Safari 全平台下默认失效或完全忽略。
accesskey 触发组合键因浏览器和系统而异
写了 accesskey="s" 不代表按 S 就行——用户必须配合修饰键，且各平台差异极大：
- Chrome / Edge（Windows/Linux）：
Alt+S，但 Chrome 90+ 默认关闭键盘激活，需手动开启chrome://flags/#enable-access-keys - Chrome（macOS）：
Ctrl+Option+S，部分版本与系统快捷键冲突（如 Spotlight） - Firefox（Windows/Linux）：
Alt+Shift+S，不是文档写的Alt+S - Firefox（macOS）：
Ctrl+Option+S，可能被 VoiceOver 拦截 - Safari（所有平台）：完全忽略
accesskey，连焦点都不给，即使开启辅助功能也无效 - 移动端（iOS Safari / Android Chrome）：全部不支持，触屏无修饰键上下文
常见“按了没反应”的真实原因
不是代码写错，而是环境或语义限制太强：
Web Accessibility (WCAG 2 AA))
下载
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
-
accesskey值不是单字符（如写了accesskey="save"或accesskey="ctrl+s"）→ 浏览器静默忽略 - 目标元素不可聚焦：比如
<div> 没加 <code>tabindex="0"，或<span></span>默认不能获得焦点 - 多个元素用了相同
accesskey值（如两个按钮都设accesskey="s"）→ 行为未定义，浏览器可能随机选一个或全不响应 - 用户当前焦点在
<input>内 → 多数浏览器跳过全局accesskey触发 - Chrome 120+ 默认禁用键盘激活，仅通过可访问性 API 暴露，实际按键无任何反应
- 监听
keydown，用e.ctrlKey && e.key === 'k'判断Ctrl+K，比依赖浏览器玄学触发稳定得多 - 加
e.preventDefault()阻止浏览器默认行为（如Ctrl+S保存页面） - 对容器元素（如
<div>、<code><td>）加 <code>tabindex="0"后再调用.focus() - 用
when条件控制作用域（例如只在编辑器区域响应Ctrl+Enter提交） - 在 UI 上显式提示：“搜索（
Ctrl+K）”，而不是靠用户猜或查文档
比 accesskey 更可控的替代做法
真要实现键盘导航增强，优先用 JavaScript 自己掌控逻辑：
真正上线前，必须在目标用户的主流浏览器+系统组合中逐个验证，不能只测 Chrome Windows 就认为“已支持”。Safari 和移动端基本放弃 accesskey 是现实选择，而非技术妥协。
