accesskey 属性虽支持键盘快捷访问，但因浏览器支持不一致、屏幕阅读器兼容性差、用户难以发现而基本不可靠；chrome/firefox/safari 触发方式各异且易被系统快捷键劫持；若必须使用，应选低冲突数字键、添加视觉提示、仅用于语义化交互元素并避免重复；更推荐优化 tab 导航、enter/space 响应及受控的全局 keydown 监听。
accesskey 属性确实能为元素添加键盘快捷访问能力，但它在实际项目中基本不可靠——主流浏览器对它的支持不一致，屏幕阅读器兼容性差，且用户几乎不会主动发现或记住这些快捷键。除非是内部管理后台且明确要求 WCAG 2.1 Level A 的极小范围场景，否则不建议依赖它做核心交互。
为什么 accesskey 在 Chrome/Firefox/Safari 中表现不一
不同浏览器对同一 accesskey 值触发方式不同：
- Chrome（Windows/Linux）：
Alt+key；macOS 上是Ctrl+Alt+key - Firefox（Windows）：
Alt+Shift+key；macOS 是Ctrl+Option+key - Safari（macOS）：仅支持
accesskey于链接和按钮，且必须配合Tab导航后按Enter才生效，直接按组合键无效
更麻烦的是，系统级快捷键（如 Alt+F4、Cmd+W）会直接劫持组合键，导致你的 accesskey 被静默忽略。
如何让 accesskey 至少“不破坏体验”
如果必须用，优先选低冲突字母，并显式提示用户：
- 避开
a–z中易被系统/浏览器占用的键（如f、e、h、s）；推荐用数字1–9或0 - 给带
accesskey的元素加视觉提示，比如在文本后追加[<code>alt+1]（注意用 - 只设在语义明确的交互元素上：
<a></a>、<button></button>、<input>；不要用在<div> 或 <code><span></span>上（多数浏览器根本不响应） - 避免重复值：同一页面多个元素不能共用相同
accesskey，否则行为未定义
示例：
<button accesskey="1">保存</button><span class="hint"> [<code>Alt</code>+<code>1</code>]</span>
比 accesskey 更靠谱的替代方案
真正提升可访问性和效率的方式不是硬塞快捷键，而是利用已有机制：
- 确保所有可交互元素都能被
Tab键顺序聚焦，且Tabindex逻辑合理（避免tabindex="1"这类手动排序） - 对关键操作提供
Enter/Space响应：按钮默认支持，自定义组件需监听keydown并判断event.key === 'Enter'或' ' - 需要全局快捷键时，用 JavaScript 监听
document.addEventListener('keydown', handler)，但务必加条件过滤（如!event.target.matches('input, textarea, [contenteditable]')），防止干扰用户输入 - WCAG 推荐用「跳转到主内容」链接（
<a href="#main" accesskey="s"></a>）+id="main"，这是少数被广泛支持的用法
真正难的不是绑定一个键，而是让快捷逻辑不和用户习惯、系统设置、当前焦点状态打架。很多团队花半天调 accesskey，不如花十分钟理清 Tab 流和焦点管理。
