别让辅助技术“瞎折腾”：HTML ARIA 属性的实战避坑指南

很多前端同学在接手老旧项目，或者开发复杂交互组件时，总会遇到屏幕阅读器“读不懂”的尴尬。这时候，ARIA（Accessible Rich Internet Applications）属性往往成了救命稻草。但如果你只是盲目地给元素贴上 role，很可能反而制造了新的障碍。真正的无障碍优化，不是堆砌属性，而是精准干预。

原生语义永远优于 ARIA

在掏代码库找 ARIA 文档之前，先问自己一个问题：这个标签真的不能用原生的吗？

开发者最容易踩的坑，就是把普通的 <div> 或 <span> 强行改成按钮。比如一个购物车结算功能，写成了 <div role="button" tabindex="0">结算</div>。这看似解决了焦点问题，却忽略了浏览器原生 <button> 自带的回车触发逻辑和默认样式。屏幕阅读器识别原生控件的速度远快于模拟控件。能用 <button> 就不用 div + role，能用 <input type="checkbox"> 就别用 div + aria-checked。这是铁律，原生语义不仅性能更好，维护成本也更低。只有当设计需求彻底突破了 HTML 标准控件的能力边界时，才考虑引入 ARIA 进行补充。

补全“角色、状态、名称”三角形

仅仅添加 role 往往是不够的。屏幕阅读器需要理解三个维度的信息才能正确播报：角色是什么？当前状态如何？叫什么名字？

假设你做了一个可折叠面板，标题是可见的。如果只加 role="heading"，读屏用户不知道下面有没有内容隐藏。这时你需要配合 aria-expanded 来控制状态变化。当展开时设为 true，收起时改为 false，屏幕阅读器就会在焦点切换时播报“展开”或“收起”。

更关键的是命名。如果界面上有两个关闭按钮，一个是关闭弹窗，一个是删除文件。若两者都只有图标没有文字，读屏软件会困惑。务必使用 aria-label 为不可见的图标按钮提供文本描述，或者通过 aria-labelledby 引用页面上已有的可见文本标题。这能确保用户知道操作后果，而不仅仅是听到一个冷冰冰的“按钮”。

动态内容的“即时广播”机制

静态页面做好结构后，最麻烦的是 Ajax 请求返回后的反馈。用户提交表单后，服务器返回错误信息，若仅仅是将一段报错文字插入 DOM，视障用户可能完全感知不到页面发生了变更。

这时候需要用到 aria-live 区域。在显示错误信息的容器上添加 role="status" 或 aria-live="polite"。这样当新内容加载进来，屏幕阅读器会在当前播报结束后自动插播提示，打断性适中。切记不要对所有动态区域都用 aria-live="assertive"，否则会频繁打断用户的正常浏览节奏，造成极差的体验。只有在报警、倒计时结束等紧急场景下，才使用强打断模式。

视觉隐藏与逻辑隐藏的区别

为了美观，我们常用 CSS 把某些装饰性图标隐藏起来，比如多余的搜索箭头。如果这个箭头对无障碍没有意义，记得加上 aria-hidden="true"，告诉读屏软件忽略它，防止重复朗读干扰信息。

反之，如果某个重要提示信息被视觉上隐藏（比如为了排版），绝对不能加 aria-hidden。曾经有案例，设计师把必填项的星号标红并隐藏在输入框内，结果因为加了该属性，视障用户根本看不到必填提示。CSS 的 display:none 会自动屏蔽读屏，但视觉隐藏（如 opacity:0）不会，此时必须手动管理 ARIA 属性以确保信息同步。

测试才是最终验收标准

代码写得再漂亮，不跑一遍测试都是耍流氓。本地调试时，建议开启系统自带的读屏工具，Windows 上用 NVDA，Mac 端直接开 VoiceOver。不要只看 Chrome 控制台里的无障碍树是否完整，要真正去听、去操作。

很多时候，布局层级混乱会导致焦点顺序错乱。检查 tabindex 的值是否为非零正数，这会破坏默认的导航流。保持 tabindex="0" 用于原生不支持焦点的元素，其余情况优先依赖 HTML 本身的聚焦顺序。 无障碍建设不是一次性的任务，而是融入每一次需求评审的习惯。当我们不再把 ARIA 当作补救措施，而是作为架构设计的一部分时，产品才能真正做到包容与友好。