原生默认无障碍，无需role或aria属性；仅非语义化标签模拟按钮时才需手动补全键盘支持与可访问名称。
原生 <button></button> 元素默认就无障碍，不需要额外加 role 或 aria- 属性；只有当你用非语义化标签（比如 <div>、<code><span></span>）模拟按钮行为时，才必须手动补全键盘支持和可访问名称。
为什么别给 <button></button> 加 role="button"
浏览器对 <button></button> 有内置语义、焦点管理、Enter/Space 响应、表单提交行为——加 role="button" 不但多余，还可能触发校验警告或导致读屏器重复播报。更严重的是，有些开发者顺手加上 aria-disabled="true" 却忘了同步控制原生 disabled 属性，结果状态不同步：视觉上灰了，但读屏器仍提示“可点击”。
- 错误写法：
<button role="button" aria-disabled="true">提交</button> - 正确写法：
<button disabled>提交</button>（浏览器自动处理所有无障碍逻辑） - 若需动态禁用，用 JS 改
el.disabled = true，而非只设aria-disabled
纯图标按钮必须配 aria-label 或 aria-labelledby
当按钮内只有 <svg></svg> 或 Emoji，没有可见文字时，屏幕阅读器无法推断其功能。此时不能靠 CSS 隐藏文字来“取巧”，必须显式提供可访问名称。
- 有旁边可见文本（如“搜索”文字紧邻图标）→ 用
aria-labelledby="search-text-id" - 完全无可见文本（如悬浮工具栏中的齿轮图标）→ 用
aria-label="设置"，且字符串必须准确反映操作意图 - 切勿写成
<button aria-label="设置">⚙️</button>同时又在 SVG 上加aria-hidden="false"——aria-hidden="true"才是正确配对，否则图标可能被重复朗读
自定义按钮（<div> / <code><span></span>）要补三件事
用非原生标签做按钮，等于主动放弃浏览器默认保障，你得自己实现全部交互链路。缺一不可：
- 加
role="button"告诉读屏器“这是按钮” - 加
tabindex="0"让它能被 Tab 键聚焦 - 监听
keydown事件，对Enter和Space键都触发相同逻辑（不能只响应 Enter）
漏掉任一环节，键盘用户就会卡住：能聚焦、不能触发；或能触发、但读屏器不报状态变化。更隐蔽的坑是，这类按钮在表单中不会参与 form.submit()，也不响应 click 事件冒泡——除非你手动绑定并阻止默认行为。
aria-label 和 aria-labelledby 别混用，也别覆盖真实文本
这两个属性都会覆盖元素内部文本，形成最终的“可访问名称”。一旦写错，用户听到的和看到的就不一致。
- 错误：
<button aria-label="确认">删除</button>→ 读屏器只读“确认”，用户不知道点的是“删除”还是“确认删除” - 正确：
<button>删除</button>（原生语义足够），或<button aria-label="永久删除当前项目">?️</button>（纯图标+高信息量描述） - 若文案会动态切换语言或内容（如多语言站点），优先用
aria-labelledby指向一个实时更新的<span id="btn-text"></span>，而不是硬编码aria-label
最常被忽略的细节是：按钮状态变化（如加载中变成“提交中…”）时，aria-label 必须同步更新——否则读屏器永远停留在初始文案，而视觉上按钮文字早已改变。
