ARIA不是加分项而是高风险补丁，仅在自定义控件、动态内容更新、状态实时同步三类场景必须使用；滥用会破坏可访问性，且所有ARIA属性须由JS全程维护并经屏幕阅读器真实测试验证。
ARIA 属性本身不提升代码质量，写错反而直接拉低可维护性
ARIA 不是“加分项”，而是高风险补丁。它不改变 DOM 结构、不修复 JS 逻辑、不优化性能，只负责向辅助技术传递语义信息。一旦 aria-expanded 没随 JS 状态同步更新，或 aria-live 区域没触发 DOM 变更，屏幕阅读器就彻底失联——这种 bug 很难被测试覆盖，却会在线上真实影响用户。
常见拖累代码质量的表现：
-
role="button"加了，但没监听Enter和Space键，键盘用户卡死 - 多个
aria-labelledbyID 引用失效（ID 拼错、元素被移除），读屏器静默或乱读 -
aria-hidden="true"套在父容器上，结果把里面本该可访问的子控件一并屏蔽 - 用
div+role="tablist"实现标签页，却漏掉aria-selected和焦点管理逻辑
哪些地方必须加 ARIA，哪些地方加了反而有害
真正需要 ARIA 的只有三类场景，其余全是“画蛇添足”：
- 自定义控件：比如用
div实现的下拉菜单、树形选择器、开关（role="switch"） - 动态内容更新：AJAX 返回结果、搜索建议列表、表单校验提示，靠
aria-live="polite"主动通知 - 状态实时同步：折叠面板展开态、多选按钮选中态，必须用
aria-expanded或aria-checked并由 JS 动态维护
以下情况加 ARIA 就是破坏可访问性：
立即学习“前端免费学习笔记（深入）”；
-
<button>提交</button>再加aria-label="提交表单"：覆盖原生文本，导致重复播报或只读 label -
<header role="banner">：HTML5header已隐含role="banner"，重复声明可能被忽略或触发警告 -
<h2>设置</h2>加aria-label="用户设置页面"：标题可访问名称就是自身文本，覆盖后信息丢失 -
<img src="logo.png" aria-label="公司 logo">：应该用alt，aria-label在img上无效或行为不可靠
如何让 ARIA 和原生语义安全配合
核心原则：ARIA 只负责“说清楚”，原生结构负责“做正确”。二者不是叠加关系，而是分工协作：
- 表格必须用
table+th+scope，别用role="grid"模拟——后者缺失排序、筛选等原生能力 - 搜索框应套在
<form role="search">中，但输入框本身必须是<input type="search">，而非div contenteditable - 模态框要同时满足：
role="dialog"、aria-modal="true"、焦点锁（focus trap）、aria-labelledby指向标题，缺一不可 - 所有
aria-属性一旦出现，就必须由 JS 全程维护：点击后没改aria-expanded，等于没写
测试时最容易被忽略的关键点
写完 ARIA 不等于做完可访问性。真实影响用户的，永远是运行时行为：
- 用键盘 Tab 导航，看焦点是否能进入、是否卡住、是否顺序合理
- 打开 VoiceOver 或 NVDA，朗读整个页面，确认关键控件有无描述、状态是否同步更新
- 模拟 AJAX 更新，检查
aria-live区域内容变化后是否被读出（polite还是assertive是否匹配场景） - 关闭 JS，观察 ARIA 属性是否让结构彻底崩坏（比如依赖
aria-hidden隐藏的内容意外暴露）
最麻烦的不是写错属性，而是写对了却忘了维护——比如切换按钮的 aria-pressed 值始终为 false，或者 aria-describedby 指向的 ID 被删了没人发现。
