accesskey需作用于可聚焦元素且配合平台特定组合键才生效：Windows/Linux为Alt或Alt+Shift+单字符，macOS为Ctrl+Option+单字符；须避系统冲突键、加视觉提示，并优先用JS监听实现可靠快捷操作。
accesskey 属性怎么写才生效
不是所有 accesskey 值都能被触发，浏览器和操作系统对快捷键组合有硬性限制。Windows/Linux 下必须配合 Alt（Firefox）或 Alt+Shift（Chrome/Edge），macOS 则是 Ctrl+Option。直接写 accesskey="s" 不会响应单按 S。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 优先选单字符，如
accesskey="s"、accesskey="1"；避免accesskey="save"（只取首字符） - 避开系统级快捷键：不要用
"f"（Firefox 地址栏）、"t"（新标签页）、"w"（关闭窗口）等 - 在按钮、链接、输入框等可聚焦元素上使用，
<div accesskey="x">默认不生效，需加tabindex="0" - Chrome 120+ 对
accesskey的提示气泡做了弱化，用户可能根本不知道快捷键存在，务必搭配视觉提示（如括号标注 “(S)”）
如何让 accesskey 在表单控件中可靠触发
accesskey 在 <input>、<textarea> 上容易失效，尤其当焦点已在其他输入框时——浏览器通常只把快捷键路由给当前聚焦元素的父级或同级可访问节点。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 给表单控件显式设置
tabindex="0"，确保它能参与顺序聚焦：<input type="text" accesskey="e" tabindex="0"> - 避免在
<label>上设accesskey期望聚焦关联控件；应直接放在控件本身 - 若控件被
display: none或visibility: hidden隐藏，accesskey完全失效；可用position: absolute; left: -9999px替代 - React/Vue 等框架中，动态渲染可能延迟挂载
accesskey属性，建议在useEffect或mounted后确认 DOM 已写入
accesskey 与 aria-keyshortcuts 的区别和取舍
accesskey 是 HTML 全局属性，原生支持但行为不一致；aria-keyshortcuts 是 ARIA 属性，不触发默认行为，仅作语义标注，需手动监听事件实现逻辑。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 要“按下即跳转/提交”，用
accesskey+ 原生事件（如click、submit） - 要支持组合键如
Ctrl+Shift+P，或需要跨平台统一行为，必须用aria-keyshortcuts="ctrl+shift+p"并监听keydown，解析event.ctrlKey等字段 - 二者可共存：
<button accesskey="p" aria-keyshortcuts="ctrl+shift+p">，兼顾原生快捷和自定义逻辑 - 注意：
aria-keyshortcuts不会自动显示提示，也不影响键盘导航顺序，纯属辅助技术提示
移动端和屏幕阅读器对 accesskey 的支持现状
绝大多数移动浏览器（iOS Safari、Android Chrome）完全忽略 accesskey；NVDA、JAWS 等主流屏幕阅读器虽识别该属性，但默认不绑定操作，需用户手动启用“快捷键模式”（如 NVDA+Ctrl+K）后才能查看列表。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 不要依赖
accesskey实现核心功能可达性，它只是增强手段；确保所有操作仍可通过 Tab 键顺序访问 - 在无障碍测试中，用 NVDA 按
NVDA+Ctrl+K查看当前页面accesskey映射表，验证是否漏配或冲突 - 若产品强依赖快捷键（如编辑器、后台系统），放弃
accesskey，改用keydown全局监听 +useCallback防抖，自己管理快捷键注册表 - WCAG 2.1 不强制要求
accesskey，但若使用，必须保证唯一性、可发现性（如旁注）、可禁用（提供关闭开关）
真正难的不是写对 accesskey 属性，而是判断什么时候不该用它——当团队开始讨论“要不要加 accesskey”，往往说明交互路径本身已经不够线性了。
