ARIA属性仅在原生语义无法表达行为或状态时必须使用，用错比不用更糟；必须用于自定义控件、动态内容更新、状态实时同步三类场景，其余多数情况属画蛇添足。
ARIA 属性不是“加了就无障碍”，它只在原生语义无法表达行为或状态时才该出现；用错比不用更糟，尤其在自定义下拉、模态框、标签页这类组件里。
哪些地方必须加 ARIA，哪些地方加了反而破坏可访问性
真正需要 ARIA 的只有三类场景：自定义控件（如 div 实现的下拉）、动态内容更新（如 AJAX 加载列表）、状态实时同步（如折叠面板展开态）。其余多数情况属于画蛇添足：
-
<button>提交</button>再加aria-label="提交表单"：覆盖原生文本，导致重复播报或只读 label -
<header>加role="banner"：HTML5 已隐含该 role，重复声明可能被忽略或触发警告 -
<h2>设置</h2>加aria-label="用户设置页面"：标题可访问名称就是自身文本，覆盖后信息丢失 -
<img src="logo.png">加aria-label：应该用alt，aria-label在img上无效或行为不可靠
自定义下拉菜单的 ARIA 必须配齐这四点
只写 role="listbox" 不够，浏览器和读屏器会报“缺少必需子角色”或直接忽略。它需要完整语义链：
-
role="listbox"必须包裹role="option"（不能是div或li） - 触发按钮要加
aria-haspopup="listbox"和aria-expanded="false"，且 JS 必须同步更新该值 - 焦点管理不能靠
tabindex暴力推进——得用aria-activedescendant指向当前高亮项的 ID，并监听ArrowUp/ArrowDown键手动切换 - 若用
innerHTML =替换整个下拉内容，aria-activedescendant会失效，必须用appendChild或insertAdjacentElement
模态框打开后读屏器还在读背景？检查这三点
仅加 role="dialog" 不足以让辅助技术正确识别模态上下文。常见错误是给 <body> 加 aria-hidden="true"，结果整个页面对屏幕阅读器彻底不可见：
立即学习“前端免费学习笔记（深入）”；
- 必须同时满足：
role="dialog"+aria-modal="true"+aria-labelledby（三者缺一不可） -
aria-labelledby必须指向一个**真实存在的、可见的、有语义的标题元素**（如<h2 id="modal-title">确认删除</h2>），不能是空span或 JS 动态生成后未插入 DOM 的节点 - 打开模态框时，必须用
focus()主动将焦点移到首个可聚焦元素（通常是取消按钮或标题），否则键盘用户卡在背景 - 禁止对
<body>加aria-hidden="true"——这会让整个页面从可访问树中消失；正确做法是给背景容器加inert或用tabindex="-1"+ 焦点捕获
aria-live 区域不朗读？DOM 更新方式错了
aria-live="polite" 不是“加了就生效”，它依赖更新方式和插入位置。最常踩的坑是把新内容塞进错误的地方：
- 必须把新内容**直接插入到
aria-live容器内**（比如container.appendChild(newEl)），不要用innerHTML =替换整个容器，否则旧引用丢失 - 如果用 React/Vue 等框架，确保更新后 DOM 真实插入——虚拟 DOM diff 可能绕过
aria-live检测机制 -
aria-live="assertive"用于错误或关键提示，但慎用，会打断当前朗读；aria-live="polite"适合非紧急更新（如列表追加） - 禁止在
aria-live区域里嵌套交互控件（如按钮），读屏器可能跳过或误读其状态
所有 aria- 属性一旦出现，就必须由 JS 全程维护：点击后没改 aria-expanded，等于没写；ID 引用拼错或元素被移除，读屏器就静默或乱读。这不是配置问题，是逻辑契约。
