accesskey几乎无人使用，因其需记忆键位、组合键触发且无提示反馈，导致交互链路断裂；仅内部或高无障碍要求系统在满足单字母、避保留键、显式提示三条件下可保留；更优解是优化语义结构、焦点流与原生键盘行为。
绝大多数用户根本不会用 accesskey，它在真实场景中基本处于“写出来就等于没写”的状态。
为什么 accesskey 几乎没人用
不是用户懒，是交互链路天然断裂：需要同时记住键位（比如 accesskey="s"）、主动触发（Alt+S 或 Ctrl+Alt+S，不同系统/浏览器组合不同），且页面不提示、无视觉反馈。实测数据表明，普通用户点击率与 accesskey 触发率相差三个数量级——前者是“看见就点”，后者是“知道有、记得住、按得准、刚好想用”。
常见错误现象包括：accesskey 冲突（如 Chrome 默认用 Alt+/ 打开开发者工具，若设 accesskey="/" 就直接被拦截）；屏幕阅读器支持不一致（NVDA 支持较好，VoiceOver 基本忽略）；移动端完全失效（没有物理键盘）。
哪些场景下还值得保留 accesskey
仅限内部系统或高无障碍要求的政务/医疗类站点，且必须满足三个条件：
- 所有
accesskey值为单字母，避开浏览器/OS 保留键（如"f"（查找）、"r"（刷新）） - 每个可聚焦元素都提供显式视觉提示，例如悬停时在按钮右上角浮现小标签
[S] - 在页脚或帮助页用自然语言说明：“快捷键：按
Alt+S跳转到搜索框（Windows/Linux）或Ctrl+Option+S（macOS）”
更靠谱的替代方案：用原生语义 + 键盘流代替硬编码快捷键
用户真正需要的是“快速到达”，不是“按某个组合键”。与其押宝 accesskey，不如做这几件事：
- 确保
tabindex顺序合理，关键操作（如搜索、登录）靠前；主流程控件用tabindex="0"显式纳入流，非关键区域用tabindex="-1"排除 - 为搜索框等高频入口添加
autofocus（首屏加载即聚焦），或在路由变化后用element.focus()主动聚焦 - 用
aria-labelledby或aria-label明确描述控件作用，比记accesskey="c"看得懂多了 - 复杂表单可用
Enter提交、Escape关闭模态框——这些是用户已形成的肌肉记忆，无需额外学习
真正难的不是加一个 accesskey 属性，而是判断用户此刻是否真的在找“键盘捷径”——多数时候，他们只是想快一点完成任务，而最短路径往往藏在语义结构和焦点管理里，不在快捷键列表中。
