# 無障礙聲明範例：發布前應該先確認什麼？

English version: [https://accesserty.com/en/ai/guides/accessibility-statement-example-before-you-publish.md](https://accesserty.com/en/ai/guides/accessibility-statement-example-before-you-publish.md)

Page version: [https://accesserty.com/guides/accessibility-statement-example-before-you-publish/](https://accesserty.com/guides/accessibility-statement-example-before-you-publish/)

Last updated: 2026-10-03

範例和產生器可以幫助起稿，但一份有用的無障礙聲明不能只貼上漂亮文字。這篇說明網站維護者發布前應確認的範圍、標準、限制、回報管道與維護節奏。

## 重點整理

- 好的無障礙聲明範例不是一段保證文字，而是讓使用者知道範圍、標準、限制與回報方式。
- W3C WAI generator 適合用來起稿；發布前仍要依網站實際狀態補上具體內容。
- Accesserty Signal 可顯示已收錄、且符合網站網址範圍的聲明連結；顯示連結不代表它已評估聲明是否完整或網站是否符合標準。

## 先決定這份聲明要幫誰

無障礙聲明常被拿來當合規文件，但它首先應該服務遇到阻礙的人。當使用者無法送出表單、看不懂錯誤提示、操作不了選單或需要替代方式時，聲明應該能提供下一步。

所以，範例或範本只能當起點。發布前要確認文字是否真的回答使用者會問的問題：這個網站涵蓋哪些範圍、目前依照什麼標準、哪裡可能還有限制、遇到問題要找誰。

## 一份可用聲明至少應該包含什麼

W3C WAI 的 accessibility statement guidance 建議，聲明至少應包含對身心障礙者無障礙的承諾、適用的無障礙標準，以及使用者遇到問題時的聯絡方式。這是最低基礎，不是完整終點。

更實用的聲明通常還會補上已知限制、組織已採取的措施、技術前提、測試過的環境，以及適用的在地法規或政策。這些資訊不需要寫得像檢測報告，但要具體到使用者和維護者都能理解。

- 網站或服務名稱：清楚指出這份聲明涵蓋哪個網站、App、服務或版本。
- 適用範圍：說明是否涵蓋整站、部分頁面、登入後流程、PDF、第三方內容或行動 App。
- 標準與狀態：說明參考 WCAG 2.2、WCAG 2.1、EN 301 549 或在地要求，以及目前是完全符合、部分符合、尚在改善或尚未完整評估。
- 已知限制與替代方式：用使用者能理解的語言描述問題，不只列出成功準則編號。
- 回報管道：提供可用的表單、email、電話或其他聯絡方式，並說明預期回應方式或時間。
- 維護資訊：列出更新日期、評估方式、負責部門或後續改善節奏。

## 虛構範例：尚未完成全面評估的圖書館網站

以下「青溪圖書館」完全是虛構情境，用來示範寫法，不是 Accesserty 的聲明、實測成果或可直接發布的保證。範例中的檢查、限制與替代服務，只有你的網站確實有相同情況才可採用。

「我們希望每個人都能查找館藏及使用圖書館服務。本聲明涵蓋青溪圖書館網站的首頁、館藏搜尋與聯絡頁；外部借閱系統不在本次評估範圍，不能由這份聲明推論其狀態。」

「我們以 WCAG 2.2 AA 作為改善目標，尚未完成全面符合性評估。目前已檢查上述頁面的鍵盤搜尋與表單錯誤提示；尚未完成螢幕閱讀器驗證，不能將目標寫成已符合。」

「已知限制：部分舊刊物 PDF 尚無標籤結構，閱讀順序可能不清楚。若需要內容，請透過網站聯絡頁的電子郵件入口索取純文字版本。這個替代服務只有在團隊確實能提供時才能寫入正式聲明。」

「回報時，請提供頁面網址、想完成的操作，以及遇到的阻礙；不需要附上密碼或證件。聯絡表單無法使用時，可改用同頁列出的電子郵件。收到後由網站維護窗口確認問題並告知下一步。」

## 發布前必須換成你的真實資料

上面的短範例刻意沒有替你填入符合程度、測試版本或承諾回覆天數。把以下欄位填入實際資料；未知就說明尚未完成，不要把預定要做的檢查寫成做過。這份教學不是各地法定聲明格式的替代品。

- 服務與範圍：\[網站名稱與網址\]、\[涵蓋的頁面及流程\]、\[未評估範圍\]。未評估不代表可把責任一律推給第三方。
- 檢查證據：\[檢查日期\]、\[頁面或版本\]、\[方法\]、\[瀏覽器／作業系統／輔助科技及版本\]。AX tree 或模擬畫面不是實際朗讀證據。
- 限制與替代方式：\[使用者會遇到什麼\]、\[可以怎麼完成同一件事\]、\[負責窗口\]。先確認替代方式真的可用。
- 聯絡與回覆：\[表單或電子郵件\]、\[另一種可用管道\]、\[團隊做得到的回覆安排\]。不要照抄不存在的信箱或任意回覆天數。
- 維護：\[最後更新日期\]、\[負責維護的人或部門\]、\[何時重新確認\]。網站變更後檢查聲明是否仍屬實。

## 使用 generator 時，不要讓範本替你做判斷

W3C WAI 的 Accessibility Statement Generator 是可靠的起稿工具。它可以協助整理基本資訊、組織已採取的措施、技術資訊、回報與申訴流程，並且是在瀏覽器中產生可下載內容。

但產生器無法知道你的網站實際範圍、哪些頁面測過、哪些流程仍有問題、第三方內容是否在控制範圍內。這些判斷必須由網站維護者、產品團隊、法務或無障礙專家依實際情況補上。

## 避免把聲明寫成過度承諾

最危險的聲明不是寫得不夠漂亮，而是寫得過度確定。例如「完全符合所有無障礙標準」或「100% accessibility compliant」如果沒有範圍、日期、測試方式與已知限制，反而會降低可信度。

比較誠實的寫法是：說明目前依據什麼標準、已檢查哪些範圍、哪些問題正在改善、使用者遇到阻礙時可以怎麼聯絡。這樣的聲明比較像維護入口，而不是一次性的品牌宣示。

## 發布後還要讓它被找到

一份寫得好的聲明如果藏在難找的位置，實際效果仍然有限。W3C WAI 建議聲明應該容易找到，可以從頁尾、說明選單、網站地圖、關於頁或其他顯眼位置連到聲明。

連結文字也應一致且清楚，例如 Accessibility 或 Accessibility Statement。不要只放在圖片、PDF、模糊政策頁或需要多次互動才找得到的位置。

## Signal 如何顯示聲明連結

Accesserty Signal 依已收錄紀錄的網域與路徑範圍比對網站網址，可顯示適用的聲明連結；這不是對目前網頁的即時搜尋，也不是聲明完整性的評估或品質背書。發布清楚的聲明不代表一定會出現 Signal 徽章，沒有顯示也不代表網站沒有聲明。請開啟原始連結，確認聲明的範圍、日期、限制與回報方式；不要把徽章當成網站認證或整站符合保證。

對網站維護者來說，目標不是寫出一段最安全、最漂亮的文字，而是建立一個能被找到、能被理解、能持續更新的公開入口。這比單純追求「範例長得像不像」更重要。

## 延伸閱讀

- [使用 W3C WAI 無障礙聲明產生器起稿](<https://www.w3.org/WAI/planning/statements/generator/>) — 先整理實際檢查的範圍與已知限制，再填入產生器；產出的草稿仍需確認，不能代替網站檢測。

- [讓讀者找得到聲明與聯絡方式](<https://accesserty.com/guides/why-accessibility-statements-should-be-easy-to-find/>)

- [無障礙聲明術語頁](<https://accesserty.com/glossary/accessibility-statement/>)

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

- [如何閱讀無障礙聲明](<https://accesserty.com/guides/how-to-read-accessibility-statements/>)

- [W3C WAI：Developing an Accessibility Statement](<https://www.w3.org/WAI/planning/statements/>)

- [網站資料處理說明](<https://accesserty.com/data-handling/>) — 了解 Pulse 與 Signal 會收集什麼、不會收集什麼，以及公開訊號和私有資料的差異。

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