aria-keyshortcuts仅声明快捷键语义，不触发行为；须作用于可聚焦交互元素（如button、role="button"），键名须符合w3c规范（如ctrl+s），并配合keydown监听与视觉提示才能实现完整快捷键功能。
aria-keyshortcuts 不会触发任何行为，只向辅助技术（如屏幕阅读器）声明“这个元素通常用哪些键激活”。它不是快捷键执行机制，而是语义标注——告诉用户“你可以按什么来操作它”。
aria-keyshortcuts 必须配合语义化角色或原生可交互元素
它对 <div> 或纯文本节点无效，必须作用于有交互能力的元素上：
<ul>
<li>带 <code>role="button"、role="menuitem"、role="tab" 的元素
<button></button>、<a href></a>、<input>、<textarea></textarea>
tabindex="0" 保证键盘可聚焦错误示例：<div aria-keyshortcuts="Ctrl+S">保存</div> —— 屏幕阅读器会读出快捷键，但该元素无法被键盘聚焦或触发，信息完全脱节。
键名写法必须严格遵循 W3C Key Names 规范
大小写敏感，分隔符只能是 +，空格会导致解析失败：
- ✅ 正确：
aria-keyshortcuts="Ctrl+S"、aria-keyshortcuts="Alt+F4"、aria-keyshortcuts="Escape" - ❌ 错误：
aria-keyshortcuts="ctrl+s"（小写）、aria-keyshortcuts="Ctrl S"（空格）、aria-keyshortcuts="Cmd+S"（Mac 上浏览器实际用 Cmd，但规范要求写Meta） - ⚠️ 注意：
Meta是标准键名，Cmd和Windows是非标准别名，部分辅助技术可能不识别
不能只靠 aria-keyshortcuts，视觉提示和可发现性必须同步提供
屏幕阅读器用户能听到快捷键，但 sighted keyboard users 看不见。必须额外提供可见提示：
- 在按钮旁用
<kbd>Ctrl+S</kbd>呈现（仅视觉，无语义） - 用
title属性补充（注意：Chrome/Firefox 仅鼠标悬停显示；Edge/IE 在键盘焦点时也显示，可用但不全兼容） - 更可靠的做法：在按钮内嵌文本说明，例如「保存
<kbd>Ctrl+S</kbd>」，并确保该文本包含在无障碍名称中（通过aria-label或视觉隐藏但屏幕阅读器可读的span）
遗漏这点，等于只告诉盲人“有快捷键”，却让所有人（包括他们自己下次换设备时）根本找不到它。
它和 accesskey、keydown 监听完全正交，三者职责不同
aria-keyshortcuts 是纯声明，accesskey 是浏览器级焦点跳转，keydown 是 JS 执行逻辑——它们可以共存，但不能互相替代：
-
accesskey="s"：按下Alt+S（Win）或Ctrl+Option+S（Mac）将焦点移到该元素，**不自动触发 click** -
aria-keyshortcuts="Ctrl+S"：仅告知“这个按钮常用 Ctrl+S 激活”，**不绑定任何事件，也不影响 focus** -
keydown监听：你得自己写代码判断e.ctrlKey && e.key === 's'，然后调用click()或执行业务逻辑
真正可用的快捷键 = aria-keyshortcuts（说清楚） + keydown 监听（做事情） + 视觉提示（让人看见）。少一个环节，就有一类用户被排除在外。
