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

PDF 無障礙檢查：看起來正常的文件，還需要看哪些結構訊號？

PDF 看起來像文件，不代表輔助科技能理解它。這篇用保守方式說明文件語言、標籤、閱讀順序、標題、書籤、連結、圖片替代文字與表單欄位等結構訊號，以及 DevCheck 能協助做的初步檢查。


重點摘要

  • PDF 的外觀不等於輔助科技能理解的文件結構。
  • 初步檢查可以先看文件語言、標籤、標題、書籤、閱讀順序、連結、圖片替代文字與表單欄位等訊號。
  • DevCheck 的 PDF 檢查是本機結構訊號檢查，不是 PDF 修復、自動加標籤、PDF/UA 認證或完整合規判定。

PDF 不能只看「畫面是否正常」

很多網站維護者上架 PDF 時，第一眼會確認排版、圖片、頁碼和內容是否看起來正常。這很必要，但不夠。PDF 是固定版面文件，畫面看起來正確，不代表螢幕閱讀器、鍵盤使用者或其他輔助科技能理解文件的閱讀順序、標題層級、連結目的或表單欄位。

PDF Association 在介紹 PDF/UA 時也強調，可及 PDF 需要語意結構資訊，而不只是視覺內容。Adobe 和 Microsoft 的官方文件也把標籤、閱讀順序、圖片替代文字、表單欄位與檢查器放在 PDF accessibility workflow 裡。

所以這篇不把 PDF 無障礙說成一個簡單分數。比較實際的起點，是先看文件是否留下足夠的結構訊號，讓維護者知道它是否需要進一步檢查或回到來源文件修正。

可以先看的結構訊號

初步檢查不等於完整檢測，但它可以快速排除一些明顯風險。若文件完全沒有語言、沒有標籤、沒有可理解的標題或書籤，維護者就不應只因為視覺排版正常而放心上架。

  • 文件語言：輔助科技需要知道主要語言，才能使用較合理的朗讀規則。
  • 標籤結構：Tagged PDF 能提供段落、標題、列表、表格、圖片與其他內容的語意線索。
  • 閱讀順序：畫面上的排列不一定等於輔助科技讀到的順序，尤其是多欄、圖文混排與表格文件。
  • 標題與書籤：長文件如果沒有標題層級或書籤，使用者很難快速跳到需要的段落。
  • 連結文字：連結應讓使用者理解目的，不應只留下難以判斷的裸網址或重複的「點此」。
  • 圖片替代文字：資訊圖片需要替代文字；裝飾圖片則不應製造多餘朗讀負擔。
  • 表單欄位：可填寫 PDF 需要欄位名稱、說明、狀態與合理的操作順序。

哪些文件最值得先檢查？

不是每個網站都能立刻重新處理所有舊 PDF。比較務實的方式，是先看使用者是否需要靠這份文件完成任務。

如果 PDF 只是低流量的歷史公告，風險可能較低；如果它是申請表、活動簡章、報名規則、價目表、產品說明、醫療或金融資訊、政策文件、客服指引，或任何使用者必須下載後才能繼續完成流程的文件，就應該優先檢查。

自動檢查不能替人判斷內容是否真的可用

PDF 結構訊號可以提示風險，但不能取代人工判斷。工具可能看得到文件有標籤，卻不知道標題是否真的表達內容層級；工具可能看得到圖片有替代文字，卻不知道那段文字是否對使用者有幫助；工具也可能看得到表格結構，卻無法完整判斷使用者是否能理解資料關係。

因此比較負責任的說法是：PDF checker 可以幫你知道哪裡值得看，不應被包裝成「這份 PDF 已經可及」的最後答案。

DevCheck 在這裡能做什麼，也不能做什麼

DevCheck 的 PDF 檢查是在使用者自己的瀏覽器環境中進行，用來查看 PDF 的基本結構訊號。它適合在上架前、QA、內容維護或收到回報後，協助團隊快速判斷文件是否需要進一步處理。

它不會把 PDF 上傳到 Accesserty，不做 PDF 自動修復，不做自動加標籤，也不宣稱 PDF/UA 或法規符合。需要正式對外承諾、採購符合性、複雜表格、長文件或重要公共服務文件時，仍應安排更完整的 PDF 無障礙審查。

相關頁面