accesskey 实际可用性极低：浏览器支持不一致，chrome 默认禁用且仅聚焦不触发点击，firefox 触发需多键组合，safari 完全忽略；必须为单字符、避开系统快捷键，推荐优先保障键盘导航与语义化标签。
accesskey 能设，但别指望它真能被用户顺手用起来——浏览器支持不一致、屏幕阅读器行为混乱、键盘冲突频繁，实际可用性极低。
accesskey 属性怎么写才合法
必须是单个字符（字母、数字、标点），且最好避开系统级快捷键（比如 Alt+F 在 Chrome 打开文件菜单）；不同浏览器触发方式不同：Alt+key（windows）、Ctrl+Alt+key（Firefox）、Ctrl+key（Safari），Mac 用户还得加 Option。
-
accesskey值只能是单字符，写成accesskey="save"无效，必须是accesskey="s" - 避免用
accesskey="1"这类数字，某些浏览器会和地址栏书签跳转冲突 - 多个元素用相同
accesskey时，焦点顺序取决于 dom 位置，不可控 - 推荐只在关键操作上设，比如提交表单的按钮、返回首页的链接
Chrome 和 Firefox 对 accesskey 的处理差异
Chrome 从 90 版本起默认禁用 accesskey 的键盘激活（仅保留可聚焦能力），需手动开启：设置 → 高级 → “按访问键聚焦元素”；Firefox 则默认启用，但要求同时按 Alt+Shift+key（Windows/linux）或 Ctrl+Option+key（macos），比文档写的更绕。
- Chrome 中即使开了开关，
accesskey也不触发click事件，只把焦点移到元素上——意味着按钮不会自动点击 - Firefox 下如果元素不可见或
tabindex="-1"，accesskey会静默失败，无提示 - Safari 完全忽略
accesskey，连焦点都不给
替代方案比死磕 accesskey 更靠谱
真正影响可访问性的不是快捷键本身，而是能否用键盘完成全流程操作。与其花时间调 accesskey，不如确保：tabindex 逻辑合理、Enter/Space 可触发交互、所有交互元素有明确 role 和 aria-label。
立即学习“前端免费学习笔记（深入）”；
- 按钮用
<button></button>而非<div role="button">，前者原生支持 <code>Enter/Space - 自定义组件加
tabindex="0"后，必须手动监听keydown处理Enter和Space - 用
aria-describedby关联快捷键提示（比如“保存（Alt+S）”），比依赖accesskey更可靠
最麻烦的不是写错 accesskey，而是写了之后发现它在多数场景下根本不响应——尤其当页面用了 Web Components 或 Shadow DOM，accesskey 基本失效。