谷歌用3行代碼把ARIA干趴了，開發者集體踩坑

去年某大廠前端團隊花了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。你以為的"冗余保險"，實際是行為彩票。

檢測ARIA濫用的實戰方法

不需要成為無障礙專家，幾個簡單規則能過濾掉大部分垃圾代碼。

第一，看到role="button"就警惕。如果元素已經是

，role是多余的；如果是

或強行扮演按鈕，先問自己為什么不用真按鈕。CSS重置樣式不是借口，button的默認樣式用三行CSS就能抹平。

第二，aria-label和可見文字重復？刪。aria-label比可見文字長很多？檢查是否真的需要額外語境。我見過"Close"按鈕的aria-label寫成"Close the modal dialog and return to the main page"——屏幕閱讀器用戶被當成需要保姆式指引的群體，實際體驗是信息轟炸。

第三，用瀏覽器開發者工具的Accessibility面板。Chrome和Firefox都能顯示元素的可訪問性樹，對比"Name"和"Role"字段與你的預期是否一致。這是五秒鐘能做完的冒煙測試。

第四，也是最重要的：關掉屏幕，只用Tab鍵和回車鍵操作你的頁面。如果能完成核心任務，再打開屏幕閱讀器驗證播報內容。順序不能反——鍵盤可訪問是無障礙的底線，ARIA只是錦上添花。

某頭部云廠商的前端負責人跟我算過賬：團隊把ARIA屬性從平均每個組件4.2個砍到0.7個，無障礙測試通過率反而從61%提升到89%，維護工單下降54%。少即是多，在ARIA領域不是修辭，是數學。

回到開頭那個47萬的改造項目。最終解決方案是批量刪除而非添加——刪掉3400行ARIA代碼，替換為127處語義化HTML重構。驗收時盲人測試員的反饋很直接："終于知道自己在哪了。"

你的代碼庫里有多少行"為了無障礙而無障礙"的ARIA屬性？最近一次產品迭代后，它們和可見文字還對得上嗎？