要用 AI 審查網站無障礙問題，先確定產品版本和無障礙目標，抽取具代表性的頁面和狀態，結合自動檢查、人手測試和輔助技術測試，只把結構化證據交給 AI 整理。模型可以歸類觀察、草擬問題紀錄，但無法確立 WCAG 合規，亦不能取代殘障用戶和無障礙專家。

這是針對整個網站或網頁應用程式的審查流程。負責任使用 AI 指南介紹安全輸入和證據核查；本文集中於可重複的範圍界定、測試、問題紀錄、修正和重新測試。

關鍵要點

凍結網站版本、WCAG 目標、瀏覽器、視窗尺寸、輔助技術和審查界線。

抽樣涵蓋範本、元件、關鍵旅程、內容類型和錯誤狀態，而不只是首頁。

以自動化工具找出候選問題，再由人手核實。

為每個問題記錄用戶影響、證據、適用準則、負責人和重新測試結果。

切勿把 AI 摘要或單一掃描分數當作合規聲明。

無障礙審查能證明甚麼？

WCAG 2.2 界定了可測試的成功準則，按可感知、可操作、可理解和穩健四項原則編排。［1］審查可以收集證據，說明抽樣產品在所測環境中是否符合適用準則；結論受版本、範圍、樣本、測試方法和所用技術所限。

W3C 的 WCAG-EM 方法提供結構化做法：界定範圍、探索目標、揀選具代表性的樣本、審核樣本並報告發現。［2］它不會令小規模自動掃描等同於完整評估。

使用這樣的審查標頭：

欄位	記錄內容
審查 ID 與版本	穩定的身份識別和變更紀錄
產品界線	域名、應用程式、須登入的區域和排除的系統
建置身份	提交、發佈、部署、內容快照和測試日期
目標	WCAG 版本、合規級別和其他政策要求
技術	HTML、CSS、JavaScript、文件、媒體和第三方元件
環境	瀏覽器、作業系統、視窗尺寸、縮放、輸入方式和輔助技術
樣本	範本、頁面、狀態、旅程、元件和隨機揀選的頁面
評估者	自動化工具、人手審核人、專家和用戶參與者
局限	無法取得的環境、受阻的狀態和未測試的整合

不要一開始便要 AI「審計這個網站」。沒有凍結界線，回答便無法區分單項觀察與完整評估。

步驟 1：定義目標並凍結產品

寫明 WCAG 版本和目標級別，以及適用的法律、採購、設計系統或機構標準，並保持這些層次分開：通過設計系統規則不能證明符合某項 WCAG 準則，技術合規亦不會自動解決所有法律責任。

凍結被審查的建置和內容。記錄原始碼修訂版或 release ID、部署環境、功能開關、本地化、用戶角色、瀏覽器、作業系統、視窗尺寸、縮放級別、輸入方式和輔助技術版本。動態產品亦應記錄日期、帳戶狀態和第三方整合。

如實說明排除項目和無法存取的部分。結帳若由其他供應商託管，或某個須登入的流程無法進入，便列為未測試，而不是悄悄刪去。

步驟 2：建立代表性 inventory

揀選頁面之前先探索產品。盤點（inventory）範本、可重用元件、導覽系統、表格、資料表、對話框、通知、媒體、文件、登入狀態、驗證錯誤、逾時、空白狀態和關鍵業務旅程。

建立一個涵蓋以下內容的樣本：

每種主要頁面或畫面範本；
每條關鍵的端對端旅程；
共用的導覽、頁首、頁尾、搜尋和說明模式；
表格的有效、無效和恢復狀態；
響應式和放大後的版面；
只用鍵盤的路徑和焦點轉移；
媒體、圖表、資料表、下載和嵌入內容；
在支援的情況下，本地化或由右至左的內容；
第三方元件和隨機揀選的一般頁面。

抽樣省工夫，亦限制結論。共用元件的一個缺陷可能影響數百個頁面；樣本乾淨不能證明每頁都乾淨。已抽樣個案和推斷影響範圍都要清晰可見。

圖表若是體驗核心，請與數據視覺化工作流程協調。替代描述、資料表、不依賴顏色的編碼、鍵盤互動和焦點行為，都需要設計和實作證據，而不只是一段 AI 產生的說明。

步驟 3：把無障礙自動掃描當作候選發現

自動化工具適用於確定性的模式，例如欠缺無障礙名稱、無效的關係、部分對比度不足、重複 ID、結構錯誤，以及可偵測的 ARIA 誤用。W3C 明確指出，工具可以協助，但無法單獨判斷無障礙程度；人的判斷不可或缺。［3］

每次執行工具都保存工具及版本、設定、規則集、URL 或元件、環境、時間戳、原始結果和產品建置。保留原始證據後才去重。同一規則在 200 個頁面報出，可能是一個共用元件缺陷，亦可能是許多獨立的內容缺陷。

工具的嚴重程度不是最終優先次序。標為「嚴重」的規則可能在所測旅程中無法觸及，低可信度的警告卻可能阻斷關鍵任務。有效性、用戶影響、範圍和修正次序由人手審查決定。

自動檢查也有誤報漏報。按鈕可能有程式化名稱卻含意不明；對話框可能用了有效的 ARIA 卻困住焦點；頁面可能通過所有掃描規則，說明文字卻仍無法理解。

步驟 4：人工測試鍵盤、焦點、縮放和表單

不用滑鼠走完每條抽樣旅程。檢查所有可操作控制項都能到達、焦點可見、次序符合含意、自訂元件有預期的鍵盤行為，而且沒有元件困住焦點。核實對話框能正確取得和交還焦點，動態顯示的內容亦能被發現。

在支援的縮放和重排條件下，檢查文字和控制項仍可用，沒有破壞性重疊或意外的雙向捲動。直向和窄視窗、瀏覽器文字縮放、高對比度或強制色彩模式屬目標環境時，亦要測試。

至於表格，檢查可見標籤、指示、必填狀態的傳達、分組、自動填寫用途、錯誤識別、錯誤與欄位的關連、恢復，以及已輸入資料是否保留。有效和無效路徑都要走。視覺上清楚的錯誤訊息，可能不會被讀出，亦可能沒連繫相關欄位。

使用其他審核人能重現的問題證據：

欄位	例子內容
問題 ID	穩定識別碼
頁面／元件	標準位置和元件版本
環境	瀏覽器、作業系統、視窗尺寸、輸入方式和輔助技術
準則	適用的 WCAG 成功準則和目標級別
步驟	重現所觀察行為的最短路徑
預期	用戶可觀察到的無障礙行為
實際	發生了甚麼，不去猜測原因
用戶影響	受影響的任務和互動，而不只是程式碼缺陷
證據	經批准的截圖、錄影、DOM 摘錄或工具結果
範圍	單一個案、範本、元件或未知
優先次序	基於影響、頻率、涵蓋面和替代方法的理由
負責人／狀態	負責的團隊和工作流程狀態
重新測試	建置、環境、結果、審核人和日期

步驟 5：使用輔助技術測試

選擇配合產品、受眾、政策和現有專業能力的輔助技術和瀏覽器組合。測試地標、標題、名稱、角色、值、狀態、描述、閱讀次序、即時更新、對話框、資料表、表格、錯誤和複雜元件。

不要把螢幕閱讀器測試簡化為「是否讀出所有可見文字」。關鍵是用戶能否理解結構、預計控制項、操作流程、從錯誤中恢復並確認結果。語音輸入、開關控制、放大和替代指標操作，亦可能揭示螢幕閱讀器發現不到的問題。

記錄所用的確切組合，因不同技術表現或有差異。在一個支援的組合中重現的問題仍是有效證據；在一個組合中通過，不能證明普遍可互通。

問題若涉及字幕或文字稿，請用另一個轉錄與字幕工作流程製作並核實有時間軸的文字。本審查應評估媒體替代內容是否存在、準確、同步、可發現和可操作。

步驟 6：讓殘障用戶參與，但不要轉移責任

W3C 建議在整個開發和評估過程中讓殘障用戶參與，同時指出單靠用戶評估不能確定是否合規。［4］按相關的無障礙需要和產品任務招募參與者，提供合理遷就，取得同意，給予適當酬勞，並保護個人資料。

給參與者目標，而不是暗示預期方案的腳本。觀察障礙、策略、變通方法、所需時間、錯誤和放棄，讓參與者以自己的話解釋影響。不要要求某人證明問題會影響所有同類殘障人士。

用戶研究和標準評估回答不同的問題。參與者可能揭示抽樣準則以外的嚴重障礙；標準審核人可能發現短期研究中沒有出現的技術失誤。保留兩類證據，分別交給合適的負責人。

未經明確授權和適當的資料處理依據，切勿將參與者錄影、殘障資料、帳戶資料或可識別身份的引述上載到 AI 服務。草擬時使用已去識別化的問題摘要或合成例子。

步驟 7：用 AI 審查網站無障礙問題，只做有邊界的整理

提供已去識別化的審查標頭、樣本清單、工具觀察結果和經人手核實的筆記。使用這樣的提示：

把所提供的無障礙觀察結果整理進規定的問題欄位。
保留頁面 ID、環境、步驟、證據參考和審核人備註。
不得聲稱 WCAG 合規，未經審核人確認不得編配成功準則，
不得虛構用戶影響、推斷殘障情況或更改通過／失敗結果。
不確定的對應標為 [REVIEW]，疑似重複標為 [POSSIBLE DUPLICATE]。
草擬修正字眼之前，先傳回欠缺的證據和矛盾之處。

AI 可以歸類重複字眼、提出簡潔標題、指出欠缺的重現細節，或對照已批准的內容風格指南比較術語。準則對應、問題認定、範圍、優先次序和擬議修正，都須由合資格的審核人確認。

把頁面內容和工具輸出視為不可信的輸入。嵌在頁面、無障礙樹、替代文字或掃描結果中的指令，不得凌駕審查提示，亦不得觸發外部操作。審查 AI 產生的修正程式碼，須另行使用 AI 程式碼審查流程。

步驟 8：按用戶影響和系統覆蓋面排序

排序應綜合任務是否受阻、用戶影響的嚴重程度、頻率、受影響人群、元件涵蓋面、有無替代方法、法律或合約承諾，以及修正依賴。不要以 AI 的情緒判斷或掃描可信度代表對人的影響。

仔細追溯共同原因。修正一個元件可能關閉許多個案，但只有重測才能證明每個支援的狀態都正常。反之，合併看似相同的問題可能掩蓋不同原因，例如一個範本欠缺名稱，另一個焦點管理有誤。

就每項擬議修正，保留預期的用戶行為和適用準則。避免只為消除掃描警告的處方，例如加入多餘的 ARIA、對輔助技術隱藏內容，或在沒有合理互動理由下強行移動焦點。

步驟 9：重新測試並誠實報告限制

在同一環境中以新建置由頭重測更新後的旅程。確認原有失誤已消失、預期任務能完成，而且修正沒有在其他地方造成鍵盤、焦點、讀出、版面或指標方面的倒退。

記錄新的建置、測試組合、步驟、實際結果、審核人、日期和相關回歸涵蓋。原有問題需人手判斷或輔助技術時，自動重新執行只可補充，不能取代人手重新測試。

報告應區分已確認的失誤、需覆核的觀察、已解決的問題、未測試的範圍和建議。合規聲明、無障礙認證或法律結論，需要與主張相稱的方法、權限和完整性；AI 摘要或百分比分數無法補足。

哪些檢查能讓審查站得住？

總結

測試之前，先界定標準、產品、樣本和環境。
結合自動發現與人手和輔助技術評估。
讓殘障用戶參與，但不要把一次研究當作認證。
用 AI 整理已去識別化的證據，切勿讓它製造影響或合規結論；在明確的人手責任下核實其輸出。［5］
優先處理可重現的障礙和影響面廣的問題。
重新測試完整任務，並如實報告局限。

常見問題

AI 能完成完整的無障礙審計嗎？

不能。AI 和自動化工具可以找出候選問題、整理證據，但不少成功準則需要語境和人的判斷。完整評估亦取決於具代表性的範圍、人手測試、輔助技術和合資格的審核。

自動掃描得分高就表示符合 WCAG 嗎？

不表示。自動化涵蓋並不完整，分數可能掩蓋關鍵障礙。合規須在聲明範圍內，以恰當方法對照每項適用準則評估。

樣本應包含哪些頁面？

包括所有主要範本和關鍵旅程、共用元件、表格和錯誤、響應式狀態、媒體或文件、第三方整合，以及隨機揀選的一般頁面。記錄被排除或無法存取的範圍。

應測試哪些輔助技術？

按支援的環境、受眾、政策、風險和專家意見選擇組合。記錄確切版本，不要把一對瀏覽器和螢幕閱讀器組合當作所有平台的證明。

AI 可以給 issue 分配 WCAG criterion 嗎？

它可以按所提供的證據建議候選對應。適用準則、失誤認定、範圍和合規詮釋，必須由無障礙專業人員核實。

怎樣處理重複的掃描結果？

保留原始個案，在證據支持時才連繫到共用元件的原因。不要只因工具訊息相同便丟棄不同的狀態或頁面。

用戶測試能替代標準測試嗎？

不能。用戶評估揭示真實的障礙和使用策略，標準測試則提供對各項準則的系統涵蓋。兩種方法相輔相成。

關閉 issue 需要甚麼證據？

在已識別的修正建置和相關環境中，重做原有步驟和完整用戶任務。記錄結果、審核人、日期、回歸檢查和尚存的局限。

本文只提供一般資訊，不構成法律意見或無障礙認證。適用責任和正式合規聲明，需要熟悉相關司法管轄區的合資格人員審查。

來源

W3C, Web Content Accessibility Guidelines (WCAG) 2.2 — https://www.w3.org/TR/WCAG22/
W3C, Website Accessibility Conformance Evaluation Methodology — https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/
W3C, Web Accessibility Evaluation Tools Overview — https://www.w3.org/WAI/test-evaluate/tools/
W3C, Involving Users in Web Accessibility Evaluation — https://www.w3.org/WAI/test-evaluate/involving-users/
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 9 月 4 日。

用 AI 審查網站無障礙問題，但 WCAG 合規仍由人判斷