ARIA是什么？有什么作用？

常见误区：

• role="button" 加在
  上，却不加 tabindex="0"、不监听 Space/Enter 键 —— 它无法被键盘聚焦或触发
• 给原生 强行加 role="link" —— 浏览器和读屏器会忽略该 role，或覆盖默认行为，造成逻辑混乱
• 用 aria-label="Close" 标注一个不可聚焦、无交互的 —— 大多数读屏器根本不会朗读它（违反 ARIA Name Computation 规则）

为什么需要 ARIA：三类场景不可替代

HTML5 已覆盖大部分基础语义，但以下三类情况必须靠 ARIA 补位，否则 WCAG 合规性直接不达标：

• 自定义组件：如纯 JS/CSS 实现的
  ，需配合 role="tablist"、role="tab"、role="tabpanel" 及 aria-selected、aria-controls 等联动属性
• 动态内容更新：AJAX 加载新评论后，仅替换 DOM 不会触发读屏器响应，必须用 aria-live="polite" 包裹容器，并确保内容是通过 appendChild 或 insertAdjacentHTML 追加而非 innerHTML = ... 全量重写
• 状态缺失：图标按钮（如仅含 的“删除”按钮）没有文字内容，必须用 aria-label 或 aria-labelledby 提供明确文本，否则读屏器会跳过或读作“图形”

aria-hidden="true" 的真实作用和典型误用

aria-hidden="true" 不是视觉隐藏，它只对辅助技术生效：告诉屏幕阅读器“彻底忽略这个节点及其所有后代”。但它不影响 CSS 渲染、JS 操作或用户可见性。

容易踩坑的地方：

• 给整个
• 父元素设了 aria-hidden="true"，子元素即使写 aria-hidden="false" 也无效 —— 继承规则强制覆盖，无法绕过
• 模态框打开时把 设为 aria-hidden="true" —— 背景内容对读屏器完全不可见，但焦点仍可能逃逸；正确做法是用 inert 属性（现代浏览器支持），或手动实现焦点锁定（tabindex="-1" + focus() + keydown 拦截）

验证 ARIA 是否真起作用：别信 DevTools 的“Accessibility”面板

浏览器开发者工具只检查属性是否存在，不校验逻辑是否连贯。例如 aria-expanded="false" 点击后没变成 "true"，或 aria-live 区域内容更新但 DOM 是通过 innerHTML 替换的（会中断 live region 监听），辅助技术就完全失联。

必须实测：

• 用 NVDA（Windows）或 VoiceOver（macOS）开启后完整走一遍交互流程：打开/关闭、Tab 导航、状态切换、内容加载
• 观察焦点是否卡在模态框内、aria-live 区域是否被朗读、aria-pressed 变化是否同步触发语音反馈
• 特别注意“虚拟光标模式”（VoiceOver）和“浏览模式”（NVDA）下行为差异 —— 同一段代码在这两种模式下可能表现完全不同

最常被忽略的一点：ARIA 属性一旦写上，就必须由 JavaScript 全程维护。它不是静态声明，而是运行时契约。

今天关于《ARIA是什么？有什么作用？》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！