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

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

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


重點摘要

  • 好的無障礙聲明範例不是一段保證文字，而是讓使用者知道範圍、標準、限制與回報方式。
  • W3C WAI generator 適合用來起稿；發布前仍要依網站實際狀態補上具體內容。
  • Accesserty Signal 會把清楚、可找到的聲明視為公開訊號，但它仍不是認證或完整符合保證。

先決定這份聲明要幫誰

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

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

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

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

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

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

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

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

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

避免把聲明寫成過度承諾

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

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

發布後還要讓它被找到

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

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

Accesserty 如何看待這類聲明

Accesserty Signal 會把找到的公開無障礙聲明視為一種可追溯訊號。這代表使用者可以更快看到網站有公開說明與回報入口，但不代表 Accesserty 認證該網站，也不代表整站沒有問題。

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

相關頁面