跳至中央內容區塊 :::
:::

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

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

最後更新:

重點摘要

  • 好的無障礙聲明範例不是一段保證文字，而是讓使用者知道範圍、標準、限制與回報方式。
  • 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 徽章，沒有顯示也不代表網站沒有聲明。請開啟原始連結，確認聲明的範圍、日期、限制與回報方式；不要把徽章當成網站認證或整站符合保證。

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

相關頁面