aria不是加分项而是高风险补丁，仅在自定义控件、动态内容更新、状态实时同步三类场景必须使用；滥用会破坏可访问性，且所有aria属性须由js全程维护并经屏幕阅读器真实测试验证。

ARIA 属性本身不提升代码质量，写错反而直接拉低可维护性

ARIA 不是“加分项”，而是高风险补丁。它不改变 DOM 结构、不修复 JS 逻辑、不优化性能，只负责向辅助技术传递语义信息。一旦 aria-expanded 没随 JS 状态同步更新，或 aria-live 区域没触发 DOM 变更，屏幕阅读器就彻底失联——这种 bug 很难被测试覆盖，却会在线上真实影响用户。

常见拖累代码质量的表现：

• role="button" 加了，但没监听 Enter 和 Space 键，键盘用户卡死
• 多个 aria-labelledby ID 引用失效（ID 拼错、元素被移除），读屏器静默或乱读
• aria-hidden="true" 套在父容器上，结果把里面本该可访问的子控件一并屏蔽
• 用 div + role="tablist" 实现标签页，却漏掉 aria-selected 和焦点管理逻辑

哪些地方必须加 ARIA，哪些地方加了反而有害

真正需要 ARIA 的只有三类场景，其余全是“画蛇添足”：

• 自定义控件：比如用 div 实现的下拉菜单、树形选择器、开关（role="switch"）
• 动态内容更新：AJAX 返回结果、搜索建议列表、表单校验提示，靠 aria-live="polite" 主动通知
• 状态实时同步：折叠面板展开态、多选按钮选中态，必须用 aria-expanded 或 aria-checked 并由 JS 动态维护

以下情况加 ARIA 就是破坏可访问性：

Wechat HTML Publisher

直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。

下载

• <button>提交</button> 再加 aria-label="提交表单"：覆盖原生文本，导致重复播报或只读 label
• <header role="banner"></header>：HTML5 header 已隐含 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"></form> 中，但输入框本身必须是 <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 被删了没人发现。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！