谷歌用3行代码把ARIA干趴了，开发者集体踩坑|3行代码|dashboard|命令提示符|浏览器|知名企业|谷歌|阅读器

去年某大厂前端团队花了47万做无障碍改造，验收时却被屏幕阅读器用户骂上热搜——他们给每个按钮加了5层ARIA标签，结果盲人用户听到的和普通人看到的完全不是一回事。

这不是段子。ARIA（无障碍富互联网应用，Accessible Rich Internet Applications的缩写）这套本意是帮残障用户的工具，正在成为开发者自我感动的重灾区。W3C规范第一条就写得明明白白：能用原生HTML就别碰ARIA。但过去18个月，我审过的代码里83%都在违反这条。

问题不在于ARIA本身，而在于开发者把它当成了万能创可贴。

「Submit form」说了三遍，屏幕阅读器懵了

上个月我在生产环境抓到一段真实代码：

Submit form

三个属性全是废话。元素天生带role="button"，可见文字"Submit form"本身就是无障碍名称，aria-roledescription更是用自定义描述覆盖了浏览器原生的角色说明——而且覆盖的内容和原生的一模一样。

这种冗余不只是啰嗦。当你给已有可见文字的元素硬塞aria-label，部分屏幕阅读器会优先播报ARIA标签而非可见文字。一旦两者不同步——而它们一定会不同步，因为改文案时没人记得同步改ARIA——明眼人看到"Pricing"，盲人用户听到的却是"View our plans and pricing information"。

我见过最荒诞的场景：产品经理让测试"点那个Pricing链接"，测试的屏幕阅读器从头到尾没报过"Pricing"这个词。团队排查了四小时，发现是三个月前改版时只改了可见文字。

把链接伪装成按钮，ARIA在撒谎

React组件库里有个模式我见了不下二十次：

Dashboard

这段代码在欺骗用户。href属性说明这是个链接，会跳转到新页面；但role="button"让屏幕阅读器播报"Go to dashboard, button"。盲人用户听到"按钮"会预期当前页执行操作，听到"链接"才知道要跳转——这个认知差直接关乎方向感。

修复方案？删掉所有ARIA：

Dashboard

浏览器原生处理，屏幕阅读器播报"Dashboard, link"。用户明确知道即将发生什么。

这种"ARIA过载"背后有个心理机制：团队被审计出无障碍问题，有人Google"how to make accessible"，然后开始撒ARIA属性，像给火锅加辣酱——加得越多越安心。但ARIA不是辣椒，是处方药，用错地方会中毒。

ARIA的真正用武之地：HTML够不着的地方

原生HTML能覆盖80%场景，但剩下20%确实需要ARIA补位。

动态内容更新是最典型的刚需。聊天应用的新消息、股票行情的实时跳动、表单验证的错误提示——这些视觉上的瞬时变化，盲人用户需要被主动告知。aria-live区域就是干这个的：

3 new messages

内容变化时，屏幕阅读器会礼貌地插播通知，不打断用户当前操作。

复杂组件是另一块阵地。自定义下拉菜单、标签页切换、树形导航——这些没有对应HTML元素的模式，需要ARIA搭建语义框架。但这里有个铁律：先写键盘交互，再补ARIA标签。很多开发者反着来，结果屏幕阅读器能"看懂"组件，键盘用户却根本进不去。

我去年重构过一个日期选择器，原实现塞了17个ARIA属性，但Tab键根本聚焦不到日历格子。删掉12个冗余属性，重写键盘导航逻辑，测试通过率从34%跳到91%。

ARIA的隐藏成本：维护地狱

每个aria-label都是一份技术债务。产品迭代时，可见文案由产品经理、设计师、本地化团队层层把关，ARIA属性却藏在代码里无人问津。

某跨境电商平台的数据：上线两年后，37%的aria-label与可见文字存在偏差，其中12%已经造成用户投诉。最离谱的一个案例——"Add to cart"按钮的aria-label还是三年前的"Add to basket (USD)"，而购物车早就支持多货币了。

这种漂移不是疏忽，是系统性的信息孤岛。设计稿不标注ARIA，QA不测试屏幕阅读器，产品经理甚至不知道这些属性的存在。

更隐蔽的风险是ARIA的优先级规则。当aria-label、aria-labelledby、title属性同时存在时，不同屏幕阅读器的解析顺序并不一致。NVDA优先aria-labelledby，JAWS优先aria-label，VoiceOver在某些场景下会回退到title。你以为的"冗余保险"，实际是行为彩票。