# 網站無障礙回報管道應該包含什麼？

English version: [https://accesserty.com/en/ai/guides/what-an-accessibility-reporting-channel-should-look-like.md](https://accesserty.com/en/ai/guides/what-an-accessibility-reporting-channel-should-look-like.md)

Page version: [https://accesserty.com/guides/what-an-accessibility-reporting-channel-should-look-like/](https://accesserty.com/guides/what-an-accessibility-reporting-channel-should-look-like/)

Last updated: 2026-09-30

無障礙回報管道可以是有人處理的 email 或容易操作的表單。重點是入口清楚、只問必要資訊，並讓使用者知道送出是否成功。

## 重點整理

- 回報管道的目的不是取代稽核，而是讓使用者遇到阻礙時有低負擔的下一步。
- 好的回報應該保留頁面、問題類型、使用情境與可選聯絡方式，但不要求使用者提供不必要資訊。
- 對網站維護者來說，回報需要進入可追蹤流程，否則很容易停在信箱或聊天紀錄裡。

## 不要讓回報本身變成新的阻礙

當使用者已經遇到操作困難，再要求他自己找客服信箱、複製網址、描述技術細節、判斷應該聯絡哪個部門，回報本身就可能變成新的阻礙。

好的回報管道應該降低這些負擔。它不需要一次收集所有資訊，但至少要讓使用者可以用簡單方式說明「在哪裡、遇到什麼、是否需要回覆」。

## email 或表單都可以，重點是入口有人處理

有人定期查看的 email 可以是有效入口，不必為了回報另建一套系統。旁邊清楚寫「回報網站操作困難」、請對方說明頁面與卡住的步驟，並交代誰會處理，比單獨留一串地址更容易使用。

比較完整的回報管道，應該把入口、說明、欄位、狀態與維護流程連在一起。使用者只需要描述自己遇到的阻礙；網站維護者則需要把這些訊息整理成可以確認、分派與追蹤的工作。

## 保留足夠判斷的脈絡

回報越接近使用者遇到問題的現場，越容易被網站維護者理解。最基本的脈絡通常包括頁面網址、問題類型、使用者正在做的事、發生了什麼，以及是否有替代方式。

這些資訊不應該寫成審問表單。欄位越多，使用者越可能放棄。比較好的方式是先收集可協助判斷的核心資訊，再讓補充說明與聯絡方式保持可選。

- 頁面或流程：問題發生在哪個網址或哪段任務。
- 問題類型：看不清楚、按不到、無法用鍵盤、表單送不出、內容不明確或其他阻礙。
- 使用情境：裝置、瀏覽器、輔助科技或使用者願意補充的條件。
- 補充說明：讓使用者用自己的話描述，不要求他知道 WCAG 條文。
- 聯絡方式：應該保持可選，除非使用者希望收到回覆。

## 一個精簡入口可以怎麼寫

以下是設計範例，不是 Accesserty 表單的欄位規格：「在網站操作時遇到困難？請告訴我們你想完成什麼，以及在哪一步卡住。不要填入密碼、付款資料或其他私人內容。」

不必先強迫使用者選技術分類。一個能用自己的話描述問題的欄位，加上頁面或流程資訊，通常就能開始確認；裝置、瀏覽器與截圖可以之後再有節制地詢問。

- 頁面或流程：可以填網址，也可以寫「登入後的預約頁」；不要要求複製含登入憑證的完整網址。
- 想完成的事與卡住的步驟：例如「用鍵盤送出後，找不到需要修改的欄位」。
- 是否希望回覆：聯絡資料只在希望回覆時才需要；不留下聯絡資料也能回報。
- 收到後的說明：交代後續由誰查看；只有確認系統收到後才顯示「已收到」，不要自行寫未核定的回覆期限。

## 把回報入口本身測一遍

用測試環境與虛構資料，確認入口、欄位、錯誤、成功與失敗狀態都能操作。以下是驗收步驟，不是這篇文章已完成的測試結果。

- 只用鍵盤找入口、填寫、修正錯誤與送出；焦點可見且不會被困住。
- 用實際螢幕閱讀器確認欄位名稱、必填提示、錯誤與送出結果，不以 ARIA 屬性存在代替朗讀驗證。
- 測試送出失敗或網路中斷：保留已填內容，說明尚未確認收到並提供可行的重試方式。
- 若表單本身無法使用，提供真正有人處理的替代管道；不要列未維護的電話或信箱。

## 回報不是判決，也不是完整稽核

使用者回報描述的是一次實際經驗，不等於整個網站都無法使用，也不等於問題一定只在前端程式碼。它可能來自內容、設計、第三方工具、帳號狀態、瀏覽器組合，或某個特定流程。

因此回報管道應該使用謹慎語言：它提供線索，不直接判定網站好壞。網站維護者仍需要確認、重現、判斷影響範圍，必要時安排更完整的無障礙審查。

## 回報表單應該避免什麼

回報表單的設計會直接影響使用者願不願意留下線索。表單如果太像正式申訴、太像技術測驗，或本身就不易操作，使用者很可能在回報之前就放棄。

先收集確認問題所需的最少資訊。聯絡方式與截圖可以選填，不必要的敏感資料則不應詢問；提供截圖前，提醒使用者遮住個人資料、帳號與私人內容。不要要求使用者懂 WCAG，也不要把送出成功寫成網站已修好。

- 不要要求使用者判斷 WCAG 條文或嚴重度。
- 不要要求不必要的身分、健康、障礙類別或敏感資料。
- 不要使用會阻擋輔助科技或鍵盤操作的驗證機制。
- 不要把聯絡方式做成必填，除非使用者要求回覆。
- 不要把回報文字寫成自動判定、認證或法律保證。

## 讓回報進入可追蹤流程

回報管道最容易失效的地方，是收到之後沒有人知道下一步。它可能停在客服信箱、社群私訊、表單後台或某個人的待辦清單裡，最後沒有進入維護節奏。

比較可靠的做法，是讓回報至少能被標記狀態、關聯頁面、指定負責角色、補上初步檢查結果，並在需要時回覆使用者。這樣回報才不只是訊息，而是可以被處理的維護線索。

## Accesserty 在這裡扮演什麼角色

Accesserty Signal 讓使用者從目前頁面主動提交操作困難。回報先送到 Accesserty；目前已驗證網域且仍有存取權的維護者，可在 Console 查看這次存取權期間收到的回報，另行對照 Pulse 的操作線索、掃描摘要與週報。回報不會公開顯示在搜尋徽章中，接手者也不會取得前任的回報。

如果當時沒有具備存取權的維護者，回報可能只留在 Accesserty，不能假定之後驗證網域的人會收到它。Signal 不是該網站的官方客服，也不保證自動通知網站管理者或得到處理；需要直接協助時，請另外使用原網站提供的聯絡管道。

## 常見問題

### 什麼是網站無障礙回報管道？

它是讓使用者描述網站操作困難的入口。有人處理且附清楚說明的 email，或容易操作的表單，都可以使用；重點是只問必要資訊、清楚確認收到，並有人追蹤處理。

### 無障礙回報和正式無障礙稽核一樣嗎？

不一樣。使用者回報是一個實際使用情境中的線索，可以指出哪裡需要確認；正式稽核則需要完整範圍、方法、樣本、測試與專業判斷。

### 使用者需要懂 WCAG 才能回報問題嗎？

不需要。回報管道應該讓使用者用自己的話說明遇到什麼、在哪裡發生、原本想完成什麼任務，以及是否需要替代方式或回覆。

### 網站維護者收到回報後應該做什麼？

先確認收到，再確認頁面、流程、使用情境與影響範圍。接著把問題放進可追蹤流程，標記狀態、分派負責人，必要時安排人工檢查或專業審查。

## 延伸閱讀

- [收到回報後，怎麼確認、回覆與追蹤](<https://accesserty.com/guides/respond-to-accessibility-reports/>) — 回報入口只是開始；收到內容後，還需要確認受阻任務、回覆使用者並追蹤修正與重測。

- [資料處理方式](<https://accesserty.com/data-handling/>)

- [Accesserty Signal](<https://accesserty.com/signal/>) — 在搜尋結果中顯示公開無障礙訊號，並讓使用者回報遇到的阻礙。

- [Accesserty Pulse](<https://accesserty.com/pulse/>) — 觀察上線後的操作困難訊號、機器掃描摘要與使用者回報。

- [W3C WAI：表單成功與失敗通知](<https://www.w3.org/WAI/tutorials/forms/notifications/>)

- [網站上線後如何持續監測無障礙](<https://accesserty.com/guides/post-launch-accessibility-monitoring/>)

- [每週無障礙風險檢視](<https://accesserty.com/guides/weekly-accessibility-risk-review/>)

- [無障礙實作與維護指南](<https://accesserty.com/guides/>) — 依實際任務瀏覽公開訊號、上線前檢查、上線後維護與標準限制指南。