必须用role="button"的唯一场景是无法使用原生<button>而必须用<div>或<span>实现按钮行为且需补无障碍支持；此时还需添加tabindex="0"、处理Enter/Space键、提供aria-label或可见文本、实现视觉焦点反馈。
role="button" 什么时候该用
它不是用来替代 <button> 的，而是当无法用原生按钮时的兜底方案。比如你用 <div> 或 <span> 实现了一个看起来像按钮的交互区域，又必须让屏幕阅读器识别为按钮、支持空格/回车触发，这时才加 role="button"。
常见误用场景包括：给已有 <button> 再加 role="button"（多余且可能干扰语义）、在纯展示元素上加（没配键盘事件就等于摆设）。
- 必须配合
tabindex="0"，否则无法获得焦点 - 必须监听
keydown事件，手动处理Enter和Space键 - 建议同时设置
aria-pressed（用于切换类按钮）或aria-disabled（代替disabled属性）
为什么不能只写 role="button" 就完事
写了 role="button" 只是告诉辅助技术“这是个按钮”，但浏览器不会自动赋予任何行为——不聚焦、不响应空格/回车、不改变鼠标样式、不触发默认表单提交逻辑。它只是语义层的声明，不是功能层的实现。
典型错误现象：role="button" 元素用鼠标点正常，但键盘 tab 过去按空格没反应，或者屏幕阅读器读作“button”却无法操作。
立即学习“前端免费学习笔记（深入）”；
- 缺失
tabindex="0"→ 无法键盘聚焦 - 没监听
keydown→ 空格/回车无响应 - 没改
cursor: pointer和:focus样式 → 视觉反馈缺失 - 没同步更新
aria-pressed→ 切换状态对辅助技术不可见
和原生 button 的关键差异在哪
原生 <button> 自带焦点管理、键盘交互（空格/回车触发）、表单提交行为、禁用逻辑、可访问性语义，而 role="button" 需要全部手动补全。性能上没区别，但维护成本高、易出兼容性问题（尤其旧版 IE 对 ARIA 支持弱）。
使用场景仅限于：组件库封装需要高度定制渲染结构（如用 <li> 做菜单项按钮）、遗留系统无法改标签、或框架限制导致无法直接用 <button>。
-
<button>自动有type="submit"行为，role="button"完全没有 -
<button disabled>会阻止所有交互并灰显，role="button"必须靠aria-disabled="true"+ 手动 CSS + 阻止事件 - 部分安卓 TalkBack 或 iOS VoiceOver 在某些 WebView 中对
role="button"的支持不如原生<button>
一个最小可用示例长什么样
以下代码能通过键盘和鼠标触发，被屏幕阅读器正确识别，并具备基本视觉反馈：
<div role="button" tabindex="0" aria-label="删除选中项">?️ 删除</div>
对应 JS 必须包含：
element.addEventListener('keydown', (e) => {
if (e.code === 'Enter' || e.code === 'Space') {
e.preventDefault();
handleClick();
}
});
element.addEventListener('click', handleClick);
别漏掉 e.preventDefault()——空格键默认会滚动页面，必须拦截。
真正麻烦的不是加 role="button"，而是让它在所有主流辅助技术和键盘工作流里都表现一致。多数团队低估了这部分测试成本。
