原生天生具备完整可访问性链路，而自定义按钮需手动实现焦点管理、键盘响应（enter/space）、状态同步（aria-disabled/aria-busy）及语义标注（aria-label），否则90%可访问性即失效。
原生 <button></button> 元素天生具备可访问性基础，但只要加了 JS 交互、改了样式、嵌了图标或替换成 <div>，90% 的可访问性就立刻崩了。关键不是“补 ARIA”，而是守住语义边界、接管键盘行为、同步状态感知。
<h3>为什么<button>比<div role="button">可靠得多
<p>浏览器对 <code><button></button> 内置了完整的可访问链路：Tab 可聚焦、Enter/Space 可触发、屏幕阅读器自动报“按钮”、disabled 属性直接禁用交互与语音播报。而 <div role="button"> 只是告诉辅助技术“我假装是按钮”，但不自带焦点管理、不响应空格键、不继承 <code>disabled 行为——你得自己补全所有逻辑。
- 必须手动添加
tabindex="0"才能被 Tab 到 - 必须监听
keydown并判断event.key === 'Enter'或' '（注意是空格字符，不是字符串 "space"） - 必须在 JS 中显式处理
aria-disabled="true"，且不能只靠 CSS opacity 变灰 - 若用 Shadow DOM 封装，还必须桥接内部真实
<button></button>的focus()和click事件
键盘交互缺失是可访问性第一大断点
很多“动态按钮”只绑了 onclick，结果键盘用户按 Enter 没反应，按 Space 直接滚动页面——因为 <button></button> 默认响应 Space，但自定义元素不会。
- 所有可点击的非原生控件，必须同时监听
click和keydown -
keydown中只拦截Enter和ArrowDown不应阻止默认行为 - 不要用
event.preventDefault()拦所有键，否则会破坏屏幕阅读器快捷键（如 JAWS 的 Insert+Up） - 模态框内的按钮，打开后需立即
firstFocusableElement.focus()，关闭后必须triggerButton.focus()回溯
动态状态变更必须同步 aria-live 或焦点
按钮点击后弹出提示、切换加载态、展开下拉菜单——这些 DOM 变更对视觉用户明显，但对屏幕阅读器是静默的，除非你主动“喊出来”。
- 纯提示类更新（如“提交成功”）：用
<div aria-live="polite"> 包裹，innerHTML 赋新值即可 <li>面板类更新（如标签页切换、模态框打开）：插入新 DOM 后，立刻 <code>element.focus()到首个可聚焦子节点 - 禁用态切换（如“发送中…”）：除设
disabled外，还需aria-busy="true"+aria-disabled="true"，避免辅助技术误判为“可操作但没反应” - 避免用
display: none隐藏内容区域——应配合aria-hidden="true"，否则屏幕阅读器仍可能读取 - 优先用
aria-label，例如<button aria-label="发送消息"><svg>...</svg></button> - 若图标旁已有可见文本（如“发送
- 禁用
alt属性——<img>才有alt，<svg></svg>或<i></i>必须走 ARIA - 不要写
aria-label=""：空值会被忽略，等同于没写
图标按钮不加 aria-label 就等于没文字
仅含 <svg></svg> 或 <i class="icon-send"></i> 的按钮，对屏幕阅读器就是“空白按钮”。它不会猜图标含义，也不会读 class 名。
最常被忽略的其实是焦点管理——不是“能聚焦”就行，而是“聚焦到哪、什么时候聚焦、聚焦后是否可操作”这三件事必须闭环。一个按钮点击后弹窗，但焦点卡在背景层，用户按 Tab 就跳过整个弹窗，这种问题没法靠 lint 工具发现，只能靠真实键盘测试。
