accesskey不是快捷键方案，仅触发焦点且不执行操作；它跨平台行为分裂、易被系统拦截、移动端失效，Chrome 120+默认禁用，Safari需手动开启，Firefox响应有限，必须配合Enter/Space才能激活，应改用keydown监听实现可靠快捷键。
accesskey 不是快捷键实现方案，它只是个有严重限制的焦点触发提示——按组合键后只让元素获得焦点，不执行点击、不触发提交、不滚动到位置，且跨平台行为分裂、易被系统拦截、移动端完全失效。
为什么 accesskey 按了没反应
这不是你写错了，而是浏览器根本没打算让它“生效”：
- Chrome 120+ 默认禁用键盘激活，
accesskey仅暴露在可访问性 API 中，document.activeElement不会变，控制台也看不到事件 - Firefox 要求
accessibility.typeaheadfind开启才部分响应，但对accesskey本身影响极小 - Safari（尤其 macOS）需手动在「辅助功能 → 键盘」中启用“使用键盘快捷键导航”，否则直接忽略
- 所有移动端浏览器（iOS Safari / Android Chrome）静默跳过该属性，无任何 fallback 或日志
- 即使元素获得焦点，你也得再按
Enter或Space才能触发动作——它不等价于点击
哪些元素加 accesskey 才可能响应
必须满足“可聚焦 + 语义合理”两个条件，否则浏览器直接跳过：
- ✅ 天然可聚焦：
<button>、<a href>、<input>、<textarea>、<select> - ✅ 手动可聚焦：带
tabindex="0"的<div>或<span>（但需确保有role和键盘交互逻辑） - ❌ 默认不可聚焦：
<table>、<tr>、<td>、<div>（无tabindex）、<span> - ❌ 语义错误：给
<h2>或<p>加accesskey，即使加了tabindex，屏幕阅读器也不会将其视为操作入口
怎么写才不至于让用户更困惑
如果非要用，目标不是“让它工作”，而是“别让用户误以为它该工作”：
立即学习“前端免费学习笔记（深入）”；
- 值选冷门字母或数字：
accesskey="z"比accesskey="s"冲突少；避开f（查找）、t（新标签页）、r（刷新）、1–9（标签页切换） - 必须显式标注：
<button accesskey="z">撤销</button><span> (Alt+Z)</span>，不能只靠属性存在 - 必须配
title或aria-label：title="撤销上一步操作"，否则焦点到了用户也不知道干啥 - 避免重复值：同一页面多个
accesskey="z"会导致焦点行为未定义，不同浏览器表现不一 - 别在表单提交按钮上依赖它：用户按
Alt+S后只聚焦，还得再按Enter，而表单默认回车就能提交——多此一举
真正该用什么替代 accesskey
要实现“按 Ctrl+S 就保存”，accesskey 是条死路。可靠路径只有一条：
- 监听
document.addEventListener('keydown', e => { ... })，但先过滤输入场景：!e.target.matches('input, textarea, [contenteditable]') - 精确判断组合键：
e.ctrlKey && e.key === 's' && !e.shiftKey && !e.altKey（防止和系统快捷键冲突） - 主动调用业务逻辑：
saveDraft()，而非试图模拟点击 - 提供视觉反馈：比如按住 Ctrl+S 时高亮保存按钮，或在状态栏显示“已绑定快捷键”
- 把快捷键配置写进帮助文档或设置页，而不是藏在看不见的 HTML 属性里
最常被忽略的一点：用户是否知道快捷键存在，比它能不能按出来重要十倍。一个没标注、没测试、没降级的 accesskey，只会让键盘用户多一次失败的尝试。
