标签语义不完整、屏幕阅读器支持弱，需配合aria-keyshortcuts声明交互语义并手动绑定JS事件；视觉上应采用组合结构增强可读性与可访问性。
直接用 标签就能显示键盘快捷键，但浏览器默认样式简陋、语义不完整、屏幕阅读器支持弱——光套个标签远远不够。
为什么
HTML 规范定义 表示“用户输入”，但实际渲染只是加粗+等宽字体，没有任何视觉区分度。更关键的是： 不自动声明可访问性角色，屏幕阅读器通常读作“kay bee dee”，而非“Control plus C”。它也不处理组合键的层级关系（比如 Ctrl+Shift+T 中的修饰键与主键应有视觉/语义区分）。
常见错误现象：
- 把
Ctrl+S写成Ctrl+S，导致无法被辅助技术识别为组合操作 - 在按钮旁直接写
Alt+F4，但没配合aria-keyshortcuts属性，键盘用户无法通过快捷键直接触发该按钮 - 用 CSS 强行给
加阴影或背景色，却忽略高对比度模式下的可读性，导致残障用户看不见
aria-keyshortcuts 是让快捷键真正可用的关键
这个 ARIA 属性告诉辅助技术「按下哪些键能触发当前元素」，且支持语义化组合描述。它不替代 的视觉提示，而是补足其缺失的交互语义。
使用场景：
- 菜单项（
或带role="menuitem"的）需绑定快捷键时必须加 - 工具栏按钮（如“保存”“撤销”）希望支持键盘直达时必填
- 自定义模态框中“Esc 关闭”逻辑，应在关闭按钮上声明
aria-keyshortcuts="Escape"
参数差异：
-
aria-keyshortcuts="Ctrl+S"：合法，表示同时按下 Ctrl 与 S -
aria-keyshortcuts="Ctrl Shift T"：非法，空格不是分隔符，应写为"Ctrl+Shift+T" -
aria-keyshortcuts="F1"或"Escape"：单键写法，大小写敏感，必须用标准键名（见 W3C Key Names）
视觉呈现建议：别只靠
真实项目中，快捷键提示常需表达修饰键 + 主键 + 可选说明（如“在 macOS 上为 ⌘+S”）。纯 难以承载这种信息密度。
推荐结构（兼顾语义与样式控制）：
<span aria-label="Save document with keyboard shortcut">
<span aria-hidden="true">
<kbd>Ctrl</kbd><span aria-hidden="true">+</span><kbd>S</kbd>
</span>
<span class="visually-hidden">Press Control and S to save</span>
</span>
其中：
-
aria-hidden="true"确保符号“+”不被读出 -
class="visually-hidden"是 CSS 辅助类（position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip: rect(0, 0, 0, 0); white-space: nowrap; border: 0;），仅对屏幕阅读器可见 - 外层
的aria-label提供上下文，比孤立的更易理解
容易被忽略的兼容性细节
Edge 和 Chrome 对 aria-keyshortcuts 的支持已较稳定，但 Safari（尤其是 iOS）仍存在部分不触发的问题。更重要的是：即使声明了该属性，浏览器也不会自动绑定事件——你仍需在 JS 中监听 keydown 并手动判断组合键是否匹配。
例如，声明了 aria-keyshortcuts="Ctrl+Shift+K" 的按钮，必须配套监听：
element.addEventListener('keydown', (e) => {
if (e.ctrlKey && e.shiftKey && e.key === 'K') {
e.preventDefault();
element.click();
}
});
否则，快捷键只是“看起来有”，实际按了没反应。这是最常被跳过的实操步骤。
