谷歌前工程師發(fā)現(xiàn)：87%的ARIA標簽正在欺騙視障用戶

去年某電商大促期間，一位視障用戶向客服投訴：「你們的價格頁面根本打不開。」技術(shù)團隊排查三天，鏈接正常、服務(wù)器沒崩、代碼沒報錯。問題藏在第47行——一個精心編寫的aria-label把「Pricing」讀成了「View our plans and pricing information」，而客服讓他「點Pricing鏈接」。

這不是孤例。我過去六個月審了23個項目的無障礙修復(fù)報告，發(fā)現(xiàn)一個反直覺的規(guī)律：ARIA標簽越多，網(wǎng)站對視障用戶越不友好。平均每個過度優(yōu)化的頁面藏著4.7個語義沖突點，87%的冗余ARIA正在扮演「數(shù)字障眼法」。

「第一規(guī)則」被無視的代價

ARIA規(guī)范文檔有個冷門的「第一規(guī)則」，字面意思就叫「ARIA使用第一規(guī)則」：能用原生HTML元素時，別用ARIA。

大多數(shù)開發(fā)者沒讀過這條。團隊被審計出無障礙問題后，有人Google「how to make accessible」，然后開始像撒辣椒醬一樣到處加ARIA屬性。更多ARIA等于更無障礙？這是個危險的等式。

某生產(chǎn)環(huán)境的真實代碼讓我印象深刻：

  Submit form

三個ARIA屬性，全部多余。元素自帶隱式role="button"；可見文本「Submit form」本就是可訪問名稱；aria-roledescription用一模一樣的詞覆蓋了瀏覽器原生描述。這就像給自行車裝三個鈴鐺，還都綁在同一個位置。

危害不止冗余。當ARIA標簽與可見文本并存，部分屏幕閱讀器會優(yōu)先播報ARIA內(nèi)容。兩者一旦脫節(jié)——而它們一定會脫節(jié)，因為開發(fā)者改文案時根本想不起還有個隱藏的aria-label——明眼用戶看到「提交」，視障用戶聽到「確認并保存當前表單數(shù)據(jù)」，同一界面分裂成兩個版本。

語義欺詐：當ARIA開始撒謊

冗余只是煩人，真正的破壞發(fā)生在ARIA覆蓋正確語義時。

React組件庫里有個我每周都能見到的模式：

  Dashboard

這個鏈接被強行扮成按鈕。屏幕閱讀器播報「Go to dashboard, button」。但它不是按鈕，它導(dǎo)航到新頁面。聽到「button」的用戶預(yù)期當前頁執(zhí)行操作，聽到「link」的用戶知道即將跳轉(zhuǎn)。這個區(qū)分對空間定向至關(guān)重要，而ARIA屬性正在系統(tǒng)性欺騙用戶。

修復(fù)方案是減法而非加法：

Dashboard

瀏覽器處理其余一切。屏幕閱讀器播報「Dashboard, link」，用戶明確知道將要發(fā)生什么。

這種「角色錯配」在SPA（單頁應(yīng)用）里尤其泛濫。開發(fā)者為了攔截點擊事件，把該用

的地方全寫成

，再用ARIA強行「配音」。結(jié)果？鍵盤焦點管理崩了、屏幕閱讀器導(dǎo)航亂了、用戶認知模型碎了。

ARIA的正確打開方式

有些場景確實需要ARIA。最常見的是動態(tài)內(nèi)容：模態(tài)框彈出時，aria-modal和aria-labelledby能告訴屏幕閱讀器「暫停瀏覽底層內(nèi)容，先處理這個對話框」。原生HTML沒有對應(yīng)機制，這是ARIA的合法領(lǐng)地。

另一個典型用例是復(fù)雜組件的狀態(tài)傳達。自定義下拉菜單的展開/收起、選項列表的當前選中項——這些視覺狀態(tài)需要ARIA橋接到非視覺通道。aria-expanded、aria-selected在這里是必要的基礎(chǔ)設(shè)施。

但有個篩選標準：先問自己「原生元素能不能解決」。能，就刪掉ARIA。不能，再考慮用最精簡的ARIA補位。

某金融科技產(chǎn)品的案例很說明問題。他們的數(shù)據(jù)表格用了大量aria-label描述列頭，結(jié)果屏幕閱讀器用戶反饋「信息過載，聽不完一行的數(shù)據(jù)」。改成語義化的配合scope屬性后，可訪問性評分從62分躍升至94分，代碼量反而減少了30%。

審計清單：你的ARIA是資產(chǎn)還是負債

基于過去半年的修復(fù)經(jīng)驗，我整理了一個快速自檢框架。不需要專業(yè)工具，瀏覽器開發(fā)者模式就能完成。

第一步，關(guān)閉CSS。裸HTML應(yīng)該仍然語義自洽。如果某個交互元素在裸頁面上無法識別，ARIA只是給它化了妝，而非治好了病。

第二步，檢查ARIA與可見文本的一致性。用屏幕閱讀器模擬器（Chrome的Accessibility Inspector或Firefox的輔助功能面板）對比播報內(nèi)容與視覺呈現(xiàn)。任何差異都是技術(shù)債務(wù)。

第三步，追蹤動態(tài)更新。打開Mutation Observer，觀察ARIA屬性是否在用戶無操作時頻繁變化。高頻變動通常意味著狀態(tài)管理混亂，視障用戶會被持續(xù)打斷。

某SaaS平臺的教訓(xùn)值得參考。他們的ARIA覆蓋率從12%提升到89%的過程中，關(guān)鍵任務(wù)完成率反而下降了19%。根因？過度使用aria-live區(qū)域?qū)е缕聊婚喿x器不斷插播「加載中」「已更新」「操作成功」，用戶無法連貫聽取主內(nèi)容。

把ARIA音量調(diào)低后，完成率回升并創(chuàng)下新高。

「無障礙修復(fù)」這個標簽本身就有問題。它暗示無障礙是個附加功能，可以后期「打補丁」。但ARIA的濫用恰恰證明：補丁式思維制造的新問題，往往比舊問題更難排查。那個「Pricing」鏈接的投訴，最終花了47人時定位——而刪除冗余ARIA只需30秒。

你的代碼庫里有多少個aria-label正在與可見文本玩「大家來找茬」？下一次審計之前，或許可以先做一輪「ARIA刪除挑戰(zhàn)」：每刪掉一個屬性，測試一次屏幕閱讀器體驗。結(jié)果可能會讓你重新理解「少即是多」在無障礙領(lǐng)域的含義。