结论：role="button" 不该加在 <button> 上，加了反而可能破坏可访问性；只有用 <div>、<span> 等非交互元素模拟按钮时，才需加这个 role，且必须同步补全键盘行为、焦点管理和禁用逻辑。
直接说结论：role="button" 不该加在 <button> 上，加了反而可能破坏可访问性；只有用 <div>、<span> 等非交互元素模拟按钮时，才需加这个 role，且必须同步补全键盘行为、焦点管理和禁用逻辑。
为什么 button 元素上写 role="button" 是错的
原生 <button> 已隐式绑定 role="button"，浏览器和读屏器（如 NVDA、VoiceOver）靠标签名识别语义。手动重复添加：
- 在 IE11 + JAWS 下可能被跳过或解析异常
- NVDA 2018 以前版本会报“未知按钮”，朗读不一致
- axe-core 等检测工具标记为 “ARIA 属性冗余” warning，暴露协作认知偏差
- Next.js 的
app/layout.tsx中若把<button>放在错误层级，还叠加role="button"，VoiceOver 可能直接忽略该控件
什么情况下必须用 role="button"？怎么配齐行为
仅当无法使用原生 <button>（比如受限于 CSS 框架、UI 库封装、或需要自定义 shadow DOM 内部结构），而改用 <div> 或 <span> 实现点击区域时，才需加 role="button" —— 但光加这行属性毫无作用。
- 必须设
tabindex="0"，否则不在标准 Tab 流中，键盘用户根本进不去 - 必须监听
keydown，显式处理Enter和Space：后者要preventDefault()，否则触发页面滚动 - 禁用状态不能只靠
opacity: 0.5或pointer-events: none，得同时设aria-disabled="true"并拦截键盘事件 - 视觉焦点反馈必须真实：用
:focus-visible或手动加 outline，不能只依赖浏览器默认样式
常见失效场景：加了 role="button" 却被读屏报“不可操作”
这种报错几乎全是语义与行为脱钩导致的。典型表现包括：
立即学习“前端免费学习笔记（深入）”；
-
div加了role="button"，但没tabindex→ 键盘 Tab 跳过，读屏不识别为可聚焦控件 - 点了空格没反应 → 没监听
keydown或漏了preventDefault() - 点击后状态变了（比如切换开关），但
aria-pressed或aria-checked没同步更新 → 读屏仍播报旧状态 - 父容器用了
aria-hidden="true"，子元素即使写了role="button"也完全不可见 →aria-hidden是强制继承的，无法被子元素覆盖
最易被忽略的一点：role 本身不提供任何功能，它只是“声明”。你声明它是按钮，就得让它真正响应按钮该有的所有输入方式——哪怕只是复制原生 <button> 的最小行为集，也要完整实现。
