AI 生成介面容易忽略的無障礙問題：不只是配色，語意結構才是重災區

為什麼「畫面看起來很乾淨」不能作為無障礙合格的判斷依據？

因為視覺呈現跟底層語意結構是兩個獨立的層次，視覺上正常不代表底層標籤正確——一個用 <div onClick> 做出來的按鈕，畫面上看起來就是一個普通按鈕，滑鼠點擊也完全正常，但螢幕閱讀器讀取的是底層的 HTML 語意結構，不是螢幕上呈現出來的樣子，這個按鈕對螢幕閱讀器使用者來說形同不存在。

這也是為什麼無障礙問題特別容易被略過的原因：用眼睛檢查、用滑鼠操作，這個介面看起來完全沒問題，唯一能發現問題的方式是換一種檢查手段——實際用鍵盤操作一遍、或用螢幕閱讀器聽過一遍，光靠視覺檢查永遠抓不到這類問題。

AI 生成的替代文字「技術上準確但功能性失明」，這句話具體是什麼意思，能舉一個更完整的例子嗎？

技術上準確指的是文字客觀描述沒有錯誤，功能性失明指的是這段描述沒有傳達「這張圖在這個情境裡真正重要的資訊」。舉例來說，一張電商網站的產品圖，畫面是「一件紅色連衣裙掛在衣架上」，AI 生成的替代文字如果只寫「一件掛在衣架上的紅色連衣裙」，這句話完全準確，卻遺漏了螢幕閱讀器使用者在這個購物情境裡真正需要的資訊——這件裙子的材質、版型（合身還是寬鬆）、適合的場合，這些才是決定「要不要購買」的關鍵資訊，而不是「衣服掛在衣架上」這個視覺事實本身。

這個落差之所以難以自動抓到，是因為 W3C 的標準本身只要求替代文字要「服務其應有的功能」，沒有規定替代文字必須包含哪些具體內容，自動化檢查工具能驗證「有沒有填寫替代文字」，沒辦法驗證「這段替代文字有沒有抓到情境裡真正重要的資訊」，這一層判斷目前仍然需要人工介入。

「自動化工具只能抓到三到四成的無障礙問題」，那剩下的六到七成，實務上該怎麼補上？

剩下的六到七成主要落在需要「實際體驗」才能發現的問題上，這類問題無法單靠掃描程式碼或視覺檢查抓出來，需要真的用輔助技術走一遍流程。具體的做法包括：用鍵盤（不用滑鼠）從頭到尾操作一次整個介面，確認每個互動元素都能被 Tab 鍵聚焦、順序合理、Esc 能關閉彈出視窗；用免費的螢幕閱讀器（Windows 上的 NVDA、Mac 上的 VoiceOver）搭配瀏覽器實際聽一遍頁面內容，確認唸出來的順序跟資訊是否合理。

這些檢查沒辦法完全自動化，因為需要判斷的是「使用體驗合不合理」，不是「有沒有符合某個技術規格」——例如彈出視窗的焦點管理，程式碼可能技術上符合規範，但實際用鍵盤操作起來，焦點跳轉的邏輯可能還是讓人感到困惑，這種體驗層面的問題，只有親自走一遍才抓得出來。

如果團隊資源有限，沒辦法把這篇文章提到的所有檢查都做齊，該怎麼排優先順序？

如果資源有限，值得優先處理的是「影響範圍最廣、修正成本最低」的項目——語意化標籤（用 <button> 而不是 <div onClick>）跟色彩對比度這兩項，通常屬於一次設定好規則、後續能持續套用的基礎工程，成本相對可控，而且直接影響最基本的可用性（連結能不能被鍵盤聚焦，文字看不看得清楚）。

複雜互動的鍵盤導覽跟即時區域播報，雖然同樣重要，但通常需要逐一針對每個互動元件測試，時間成本較高，可以放在資源更充足時再處理；替代文字的品質檢查則建議至少針對「會直接影響使用者決策」的關鍵圖片（例如產品圖、資訊圖表）優先人工把關，裝飾性或次要的圖片可以先用 AI 生成的版本、之後再逐步補強。優先順序的核心邏輯是：先確保基本可用（能不能操作、看不看得到），再處理體驗品質（好不好用、資訊夠不夠完整）。