无障碍网页设计：ARIA属性使用指南

无障碍网页设计的核心在于“精准补位”而非盲目堆砌ARIA——只有当HTML原生语义无法准确传达组件角色、状态或行为时，才需谨慎引入ARIA属性；自定义下拉、模态框、动态内容区等典型场景需严格遵循role与aria-*的组合规范，并由JavaScript实时同步状态；而滥用ARIA（如覆盖原生按钮语义、重复设置浏览器已管理的状态）反而会破坏辅助技术体验；正确选择aria-label与aria-labelledby、理解aria-hidden的真实作用域、并始终将键盘焦点流与DOM变更同步纳入考量，才是实现真正可用、可访问、可持续维护的无障碍体验的关键所在。

ARIA 属性不是“加了就无障碍”，而是要在 HTML 原生语义无法表达行为或状态时，精准补位——绝大多数场景，删掉 ARIA 反而更安全。

什么时候必须用 role 和 aria-*？

只有当原生标签做不到、且辅助技术需要知道「这是什么」和「现在是什么状态」时，才引入 ARIA：

• role="listbox" + aria-expanded + aria-activedescendant：用于自定义下拉（div 实现的非 select）
• role="dialog" + aria-modal="true" + aria-labelledby：用于 div 模态框，缺一不可
• aria-live="polite"：仅用于动态插入内容区域（如无限滚动、表单提交成功提示），且要确保 DOM 是 append 而非 innerHTML 替换
• aria-haspopup="menu"：只加在触发按钮上，不能加在菜单容器本身；必须配合 aria-expanded 并由 JS 同步更新

哪些地方绝对不能加 ARIA？

强行覆盖原生语义，等于主动破坏读屏体验：

• 给 加 role="link" 或 role="switch" —— 它就是按钮，行为该由 JS 控制，不是靠改 role “伪装”
• 给 手动加 aria-checked="true" —— 浏览器已自动同步，重复设置会导致状态不同步
• 给 加 role="search" —— 表格结构直接断裂，触发 aria-requires-children 报错
• 对整个导航栏或 加 aria-hidden="true" 来“隐藏背景”——正确做法是用 inert 属性或焦点锁定

aria-label 和 aria-labelledby 怎么选？

核心看「描述文本是否已在页面可见」：

• 有可见文本（比如图标旁写着“搜索”）→ 用 aria-labelledby="id-of-the-text"
• 纯图标按钮、空按钮、隐藏控件 → 用 aria-label="搜索"
• 别写 发送 —— “发送”会被静音，只读“提交”
• aria-labelledby 支持跨元素组合，比如把图标 id="icon"、说明文字 id="desc"、输入框 id="input" 一起引用：aria-labelledby="icon desc input"

aria-hidden="true" 的真实影响范围

它只对辅助技术生效，视觉用户照常看到，JS 照常操作 —— 这点被误用最多：

• aria-hidden="true" 加在父容器上，子元素设 aria-hidden="false" 也无效（强制继承）
• 给图标加 aria-hidden="true" 是安全的，前提是旁边已有可见文字（如“用户名”+ 用户图标）
• 不要和 display: none 或 visibility: hidden 混用 —— 后两者本就会让读屏跳过，再加 aria-hidden 是冗余
• 真正需要“视觉隐藏但读屏可读”时，用 .sr-only 类（position: absolute; clip: rect(0,0,0,0)），而不是 aria-hidden="false"

最常被漏掉的是键盘焦点流与 aria-live 的配合：模态框打开后没锁焦点，表单提交后提示没被播报，问题不在 ARIA 写没写，而在 JS 是否同步更新了状态、DOM 是否以辅助技术可感知的方式变动。

理论要掌握，实操不能落！以上关于《无障碍网页设计：ARIA属性使用指南》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！