HTML5原生语义元素（如<header>、<nav>）已隐含对应ARIA role，无需重复添加；ARIA仅在HTML语义缺失时补位，且须配合完整属性与交互逻辑；原生表单控件可访问性更优，应优先使用。
HTML5 原生语义元素直接替代 ARIA roles
HTML5 新增的 <header>、<nav>、<main>、<aside>、<footer> 等元素，本身已隐含对应 ARIA role（如 role="banner"、role="navigation"），浏览器和读屏软件能直接识别其语义。强行叠加 ARIA role 不仅冗余，还可能覆盖原生行为，导致意外降级。
实操建议：
- 优先用
<nav>而非<div role="navigation"> - 避免写
<header role="banner">——role="banner"会被忽略或触发警告 - 检查 Lighthouse 或 axe DevTools，会提示 “ARIA role redundant with native element” 类错误
ARIA 只在 HTML 语义缺失时补位
当必须用 <div> 或 <span> 实现复杂交互组件（如自定义下拉菜单、标签页、滑块）时，ARIA 才是必要补充。此时需组合使用 role、aria-* 属性和键盘交互逻辑，不能只加 role 就算完事。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 只写
<div role="tablist">，但没给子项加role="tab"和aria-controls - 用
aria-hidden="true"隐藏内容，却忘了同步移除焦点流（需配合tabindex="-1"或 CSSvisibility: hidden） -
aria-live区域未设置polite/assertive，导致读屏打断用户操作
HTML5 表单控件自带可访问性，ARIA 是“最后手段”
<input type="date">、<input type="range">、<datalist> 等原生控件已内置标签关联、键盘导航、状态反馈。若用 div 模拟一个“看起来更酷”的日期选择器，就必须手动实现 role="dialog"、aria-modal="true"、焦点锁（focus trap）、aria-label 或 aria-labelledby —— 成本远高于直接用原生 <input>。
性能与兼容性影响：
- 原生表单在 iOS VoiceOver、NVDA、JAWS 中支持更稳定；ARIA 模拟控件在旧版 IE 或某些 Android TalkBack 版本中可能完全静默
- 缺少
for/id关联的<label>，比加错 ARIA 更致命 —— 这是最常被忽略的基础项 -
aria-describedby可用于补充说明，但不能替代<label>的必填语义
ARIA live regions 和 HTML5 output 元素的协作场景
<output> 是 HTML5 原生语义化输出容器，配合 <form oninput> 可自动更新并被读屏感知（无需额外 ARIA）。但若输出内容动态插入 DOM（比如搜索建议列表），就得用 aria-live="polite" 显式声明。
示例对比：
<form oninput="result.value=parseInt(a.value)+parseInt(b.value)"> <input name="a" type="number"> + <input name="b" type="number"> = <output name="result">0</output> </form>
这个 <output> 会自动被 NVDA/JAWS 朗读变更值；而下面这种 JS 插入的提示则需要 ARIA：
<div aria-live="polite" aria-atomic="true"> <!-- 动态插入的搜索建议文本 --> </div>
关键差异：原生 <output> 依赖表单绑定机制，ARIA live region 依赖 DOM 变更监听 —— 后者更通用，但也更易因频繁更新引发朗读风暴。
容易被忽略的一点：ARIA live region 必须在 DOM 加载完成时就存在，不能靠 JS 动态创建后才添加 aria-live 属性——读屏不会监听该属性的后续变化。
