accesskey提示应只显示单字符并注明“配合系统访问键”，避免绑定具体修饰键；其值与键盘布局无关，始终对应语义字符；需确保焦点后能触发操作，否则提示再清晰也无效。
accesskey提示必须避开物理键位，只用语义字符
用户看到的快捷键提示不是“按 Alt+Q”，而是“按 Q 键（配合系统修饰键）”。因为accesskey值本身只能是单字符（如"s"），而实际触发组合键由浏览器和平台决定——Windows Chrome 是 Alt+s，macOS Firefox 是 Ctrl+Option+s，Safari 甚至默认不响应。硬写Alt+S会误导 macOS 用户，写Ctrl+Option+S又让 Windows 用户困惑。
正确做法是：在引导层里只显示字符本身，并附带中性说明。例如：
<span>保存</span> <kbd>s</kbd> <small>（配合系统访问键）</small>
这样既符合accesskey="s"的取值规范，又不绑定具体修饰键组合。所有主流屏幕阅读器也会把accesskey值读作“s”，而非“Alt+S”。
不同键盘布局用户怎么看到适配提示
没有自动适配机制。浏览器不会根据用户键盘布局（如 AZERTY、Dvorak、中文输入法状态）改写accesskey值或提示文本。你写的accesskey="s"永远对应物理键盘上S键的位置（即e.code === 'KeyS'），与当前输入法、CapsLock、Shift 状态无关。
立即学习“前端免费学习笔记（深入）”；
- AZERTY 用户按的是
W键位置（对应 QWERTY 的 S），但你的提示仍应显示s—— 因为这是语义标识，不是物理按键图示 - 中文输入法下按
S键仍触发，无需切换到英文模式；但若用户处于全角输入状态，某些旧版 IE 可能失效（已基本淘汰） - 不要尝试用 JavaScript 检测键盘布局再动态改提示——没有可靠 API，且
accesskey行为本身不依赖布局检测
引导层里怎么避免误导和冲突
很多引导层直接写“按 Alt+S 保存”，这在 Safari 或 Chrome 120+ 上根本无效（默认禁用），还可能和密码管理器冲突。真正要防的是三类静默失败：
-
accesskey值用了数字（如"1"），被 Chrome 地址栏书签跳转劫持 - 按钮没设
tabindex="0"或不是原生可聚焦元素（比如<div>加了accesskey但没tabindex） - 提示文字和实际
accesskey值不一致（比如按钮写“保存(S)”，但代码是accesskey="v"）
检查方法很简单：打开 DevTools → Elements 面板 → 找到目标元素 → 看属性是否为accesskey="x"，再对照引导层文案是否完全一致。不一致就立刻修复，别指望用户去猜。
比提示更重要的事：确保焦点落到元素后能真干活
accesskey只负责把焦点移到元素上，不会自动触发click或submit。Chrome 下焦点到了<button accesskey="s">，但用户还得再按Enter或Space才能点击——这对效率毫无提升。
如果引导层宣传“一键保存”，实际却要两步操作，用户会立刻放弃。可行补救方式只有两种：
- 给按钮加
focus监听：element.addEventListener('focus', () => element.click())（注意防重复触发） - 干脆不用
accesskey，改用keydown监听e.code === 'KeyS' && e.ctrlKey这类可控组合，再统一在引导层标注“Ctrl+S”
后者更可靠，但意味着你要放弃accesskey的语义化和可访问性暴露——权衡点就在这里：提示写得再清楚，底层行为不可控，用户照样用不起来。
