ARIA本身不提升可访问性，错误使用会破坏屏幕阅读器理解；仅三类场景需ARIA：自定义控件、动态内容更新、状态实时同步；优先使用原生语义元素；典型错误包括冗余声明、语义与行为不匹配；ARIA只负责“说清楚”，原生结构负责“做正确”；所有ARIA属性必须由JS全程动态维护。
ARIA 本身不提升可访问性，用错、漏用或滥用时，反而会直接破坏屏幕阅读器对页面的理解——这是影响可访问性的最大风险点。
哪些场景必须用 ARIA
只有三类情况真正需要 ARIA 补位：
- 自定义控件（如用
div实现的下拉菜单），原生 HTML 没有对应语义 - 动态内容更新（如 AJAX 加载结果、搜索建议列表），需靠
aria-live="polite"主动通知辅助技术 - 状态实时同步（如切换按钮的按下态），必须配合
aria-pressed或aria-checked手动更新
其他时候，优先用 button、nav、label 这类原生元素——它们自带语义和键盘行为，不需要你“画蛇添足”加 role 或 aria-label。
哪些 ARIA 写法是典型错误
这些写法在主流屏幕阅读器（NVDA、VoiceOver、JAWS）中会引发误读或静默：
立即学习“前端免费学习笔记（深入）”；
-
<button>提交</button>再加aria-label="提交表单"：覆盖原生文本，导致重复播报或只读 aria-label -
<header role="banner">：HTML5 的header已隐含role="banner"，重复声明可能被忽略或触发警告 -
<div onclick="toggle()">菜单</div>加role="button"却没处理Enter/Space键响应：语义有了，行为缺失，键盘用户完全无法操作
错误的核心不是属性写错了，而是只改了“说法”，没补全“动作”——焦点管理、键盘事件、状态同步一个都不能少。
ARIA 和原生语义怎么配合才安全
关键原则是：ARIA 只负责“说清楚”，原生结构负责“做正确”。例如：
- 表格必须用
table+th+scope，而不是靠role="grid"模拟 - 搜索框应套在
<form role="search">中，但输入框本身用input type="search"，而非div contenteditable+ 大量 ARIA - 模态框必须同时满足：
role="dialog"、aria-modal="true"、焦点锁（focus trap）、aria-labelledby指向标题，缺一不可
测试时别只看代码有没有 ARIA 属性，要实际用键盘 Tab 导航、开 VoiceOver 朗读、观察焦点是否卡住、状态是否同步更新——这才是真实影响可访问性的环节。
最容易被忽略的是：ARIA 属性一旦写上，就必须由 JavaScript 全程维护。比如 aria-expanded="false" 在点击后没改成 true，或者 aria-live 区域内容变了但没触发 DOM 更新，辅助技术就彻底“失联”了。
