無障礙網站 SEO 指南：WCAG 2.2 與搜尋排名交集

無障礙（accessibility）跟 SEO 是兩件事，但實作上有不少交集。需要分清楚的是：哪些 WCAG 做法也有助搜尋引擎理解內容，哪些主要改善使用者與輔助科技的使用體驗，以及台灣的政府與學校網站到底被法規要求到哪裡。

先說一個容易被誤解的前提：Google 公開的排名系統文件沒有把「符合 WCAG」列為獨立的排名系統。你把對比修到 4.5:1、把焦點（focus）狀態做得漂漂亮亮，不能據此推論 Google 會直接加分。但無障礙背後那一套做法（語意 HTML、標題層級、替代文字、鍵盤可操作、行動版體驗），剛好跟搜尋引擎理解頁面的方式高度重疊。所以無障礙對 SEO 的價值多半是間接的，不是直接的。把這層關係想清楚，你才不會把資源砸錯地方，這點從 Google 搜尋中心的排名系統指南與〈Get started with Search〉就能對照出來。

重點摘述

• WCAG（Web Content Accessibility Guidelines，網頁內容無障礙指南）是 W3C 制訂的國際標準，現行版本是 2.2，2023 年 10 月 5 日成為正式建議，向下相容 2.1 與 2.0（見 W3C WAI 的 WCAG 2 總覽）。
• 語意 HTML、清楚標題、圖片替代文字及連結描述，能同時服務讀者與搜尋理解；鍵盤操作及對比則有各自的無障礙要求。INP 是效能指標，不是 WCAG 的成功準則。
• WebAIM 2026 年檢測一百萬個首頁發現，95.9% 的頁面有自動工具可偵測的 WCAG 失敗，平均每頁 56.1 個錯誤；在報告列出的常見語言中，中文頁面平均最高，為 136.2 個（WebAIM Million 2026 年調查）。
• 台灣《身心障礙者權益保障法》第 52-2 條要求各級政府機關（構）與學校網站通過第一優先等級以上的無障礙檢測並取得標章；現行規範的最低標章等級標示為 A，主管機關是數位發展部；條文可查全國法規資料庫，標章制度的細節見數位發展部的核發辦法。
• 無障礙的首要價值是讓更多人能使用網站。部分結構改善也有助搜尋理解，但不能保證排名或 AI 引用，法律義務則依適用法規及契約判斷。

目錄

• WCAG 是什麼：四原則、三等級、與台灣規範的對應
• 無障礙與 SEO 為什麼會重疊：兩套規則共用同一份 HTML
• 語意 HTML 與標題層級：讀者、爬蟲、螢幕閱讀器都靠它
• 替代文字：圖片 SEO 與無障礙的共同入口
• 顏色對比與可讀性：最常見也最容易被忽略的缺陷
• 鍵盤操作、焦點可見與 INP：互動體驗的雙重收益
• 行動版與響應式：無障礙與行動優先索引的重疊
• 怎麼檢測：Lighthouse、axe、WAVE 與手動測試的分工
• 台灣情境：法規底線、標章與 Freego 檢測工具
• 為什麼現在該投資無障礙：觸及、法規與 AI 答案引擎
• 常見誤解
• FAQ
• 結論與下週就能執行的行動清單

WCAG 是什麼：四原則、三等級、與台灣規範的對應

WCAG 是 W3C 的 Web Accessibility Initiative（WAI）維護的國際標準，講的是「怎麼讓網頁內容對身心障礙使用者可用」。它本身不是法律，但會被不同國家的法律、政策或採購規格引用。至於個別法域究竟採用哪一版、哪一級，仍要看當地法規，不能把 WCAG 直接當成全球統一的法律條文，W3C WAI 的 WCAG 2 總覽也是這樣定位它。

WCAG 的核心是四個原則，業界簡稱 POUR：

↔ 左右捲動檢視完整表格

原則	英文	一句話解釋
可感知	Perceivable	內容要能被使用者用某種感官接收，看不見就用聽的、用摸的
可操作	Operable	介面要能被各種方式操作，不能用滑鼠的人也要能走完整個頁面
可理解	Understandable	內容與操作方式要能被理解，不要讓人猜
穩健	Robust	內容要能被各種使用者代理（含輔助科技）正確解讀

這四個原則展開成指引，再展開成可測試的成功準則（success criteria）。準則分成三個等級：A、AA、AAA；要宣告符合 AA，必須同時滿足所有 A 與 AA 成功準則。W3C 並不建議把 AAA 當成整個網站的一般性政策要求，因為有些內容無法滿足所有 AAA 準則。實際合規聲明還應有明確範圍與驗證紀錄；AA 的宣告條件定義在 WCAG 2.2 的 Conformance Requirements，原則層次的整理可見 WAI 的 Accessibility Principles。

現行版本是 WCAG 2.2，2023 年 10 月 5 日成為 W3C 正式建議（Recommendation），向下相容 2.1 與 2.0。2.2 在 2.1 的基礎上新增 9 條成功準則，同時移除了已過時的 4.1.1 Parsing（解析）。新增的 9 條裡，2 條是 A、4 條是 AA、3 條是 AAA。對多數網站最有感的是 AA 那幾條：焦點不被完全遮蔽（2.4.11）、拖曳操作要有替代方案（2.5.7）、指標輸入的點擊目標至少 24×24 CSS 像素或符合例外（2.5.8）、身分驗證不能強迫進行沒有替代方式或輔助機制的認知功能測試（3.3.8），新增內容整理自 WAI 的〈What's New in WCAG 2.2〉與 WCAG 2.2 正式規範。

對一般網站來說，2.2 新增那幾條 AA 準則值得逐條認識，因為它們正好回應常見的可用性抱怨。Focus Not Obscured（2.4.11）要求元件取得鍵盤焦點時，不能被作者建立的內容完全遮住；它不要求焦點完全不受遮擋。Dragging Movements（2.5.7）要求任何需要拖曳才能完成的功能（比如調整欄寬、拖曳排序），也能用不依賴拖曳的單一指標操作完成，除非拖曳本身是必要或由使用者代理決定。Target Size（2.5.8）要求指標輸入目標至少 24×24 CSS 像素，但間距、等效控制、行內目標、使用者代理控制與必要性都有明列例外。Accessible Authentication（3.3.8）不允許把認知功能測試當成身分驗證流程的必要步驟，除非提供替代方式、輔助機制，或測試屬於辨識物件或個人內容。支援密碼管理器與允許貼上是規範列出的輔助機制例子；四條準則的細節可分別參考 WAI 對 SC 2.4.11、SC 2.5.7、SC 2.5.8 與 SC 3.3.8 的 Understanding 文件。

台灣現行的對應文件名稱是「網站無障礙規範（110.07）」，內容以 WCAG 2.1 為基礎，自 2021 年 7 月 1 日實施，由數位發展部主管。它不是「網站與行動化應用軟體無障礙規範」；行動化應用軟體另有檢測指引。截至 2026 年 9 月 21 日，標章申請仍依 110.07 版辦理；數發部已發布修正版，預定 2026 年 11 月 30 日實施，屆時不再受理 110.07 版標章申請；2026 年 11 月 29 日（含）前取得的原版標章仍有 3 年效期；現行規範全文見數位發展部的「網站無障礙規範（110.07）」頁面，實施脈絡可對照正式實施說明，切換時程則以115 年的異動公告為準。

無障礙與 SEO 為什麼會重疊：兩套規則共用同一份 HTML

要理解這個交集，可以先回到一個基本事實：搜尋引擎和螢幕閱讀器（screen reader）都需要解析頁面內容與結構，但兩者目的與處理方式並不相同。

Google 解析內容是為了檢索與排名；螢幕閱讀器則透過瀏覽器的無障礙樹與輔助科技，把內容轉成語音、點字或可操作資訊。語意正確、可在 DOM 中存取的 HTML 通常能同時幫助兩者。Google 能處理 JavaScript，但要求主要內容可供 Google 存取與算繪，也不會把 CSS content 產生的文字視為 DOM 內容；對螢幕閱讀器而言，視覺上存在卻未正確進入無障礙樹的內容也可能無法使用，分別可參考 Google 搜尋中心的入門文件與〈Fix Search-related JavaScript problems〉。

這就是交集的來源。下面這張表是整篇文章的核心，請記起來：

↔ 左右捲動檢視完整表格

做法	對無障礙的價值	對 SEO 的價值	是直接排名因素嗎
語意 HTML（例如 nav、main）	適當地標協助輔助科技導覽	清楚描述頁面結構	不等於獨立排名加分
標題層級（h1→h2→h3）	螢幕閱讀器可用它導覽整頁	幫助組織內容，行動版也應保留清楚標題	未被列為獨立因素
圖片替代文字（alt）	視障者能取得圖片資訊	幫助 Google 理解與索引圖片	圖片理解訊號
連結描述文字	知道連結通往哪裡	幫助使用者與 Google 理解目標頁面	連結脈絡訊號
鍵盤可操作	不能用滑鼠的人能操作	沒有已知的直接排名效果	否
顏色對比 ≥ 4.5:1	弱視者較能讀到一般文字	沒有已知的直接排名效果	否
行動版響應式	小螢幕與不同裝置較容易使用	Google 主要以行動版內容索引與排名	索引方式，不是獨立加分
INP ≤ 200 毫秒	點擊、輕觸與鍵盤互動較順	INP 是 Core Web Vitals 指標	頁面體驗的一部分

這張表要傳達的重點只有一句話：符合 WCAG 不是公開的獨立排名系統，但它要求的部分基本功，跟搜尋引擎讀懂網站所需的結構重疊。把基本功做好，兩邊都有機會受益；做爛了，兩邊都可能受害。想從更技術的層面理解爬蟲怎麼讀你的頁面，可以搭配這篇技術性 SEO 完整指南與 Google 搜尋中心的入門文件；連結怎麼被檢索，〈SEO Link Best Practices〉有官方建議。

語意 HTML 與標題層級：讀者、爬蟲、螢幕閱讀器都靠它

標題層級是整個交集裡投資報酬率很高的一塊。螢幕閱讀器使用者可以靠標題在頁面裡跳躍導覽；清楚的 h1、h2、h3 也能讓內容結構更容易理解。W3C 在〈Headings〉教學中建議依內容巢狀關係安排標題，並盡量避免不必要的跳級；這不是「任何跳級都自動違反 WCAG」的意思。

實務上有三個常見問題。第一，用 div 或 span 加 CSS 把字放大，偽裝成標題。視覺上像標題，但輔助科技無法把它當成標題導覽，搜尋引擎取得的結構線索也較少。第二，層級不合內容關係，例如從 h2 直接開始未說明的 h4 子層。WebAIM 2026 年的自動檢測發現，41.8% 的首頁有跳級標題，比 2025 年的 39% 高；這是結構指標，不等於每一例都自動構成 WCAG 失敗。第三，頁面有多個 h1。WebAIM 發現 18.1% 的首頁有不只一個 h1；多個 h1 也不會自動構成 WCAG 失敗，仍要看標題是否準確描述內容、結構是否清楚，統計出自 WebAIM Million 2026 年報告，判斷原則見〈Headings〉。

語意 HTML 應依內容用途使用。<nav>、<main>與<aside>可建立對應地標；<article>本身不是 landmark，<footer>是否具有全頁 contentinfo 地標則取決於所在層級。WebAIM 2026 年偵測到 46.1% 的首頁有 main 元素或地標。做法可參考W3C WAI 的 Page Regions，統計見WebAIM 報告。

站內 SEO與無障礙都受益於清楚的內容組織。優先修正影響理解及操作的結構問題，成本與效果仍依網站而異，不用固定的收益說法代替實際測試。

還有一個常被忽略、卻對中文站特別有感的標記：文件語言。在 <html> 標籤上正確設定 lang="zh-TW"，可讓輔助科技選擇正確的發音規則。WebAIM 2026 年發現 13.5% 的首頁沒有指定文件語言，對應的準則是 WCAG 3.1.1 Language of Page，數據見 該年度的 WebAIM Million 報告。但不要把 lang 跟國際 SEO 混為一談：Google 表示它主要依頁面可見內容判定語言，不依賴 lang 屬性；hreflang 是另一套頁面層級標記。lang="zh-TW" 的核心價值是讓瀏覽器與輔助科技知道內容語言，不是 Google 的語言或地區排名訊號，官方分別在〈Special tags that Google understands〉與〈Managing multi-regional and multilingual sites〉說明。

skip link（跳到主內容連結）是另一個值得提的結構細節。它通常放在重複導覽內容之前，讓鍵盤使用者能略過重複區塊、直接進主內容；WCAG 2.4.1 要求的是提供略過重複內容區塊的機制，skip link 是常見做法，但不是唯一做法。WebAIM 發現只有 17.1% 的首頁有 skip link，而且約十分之一的 skip link 無法正常運作；機制要求定義在 WCAG 2.4.1 Bypass Blocks，統計出自 WebAIM Million 2026 年的檢測。它沒有已知的直接 SEO 效果，但對依賴鍵盤的人很有感。

替代文字：圖片 SEO 與無障礙的共同入口

替代文字（alt text）是圖片的文字替代內容，寫在 <img alt="..."> 裡。對視障使用者，螢幕閱讀器可把 alt 念出來；對搜尋引擎，Google 表示會結合 alt、電腦視覺與頁面內容來理解圖片，所以 alt 是重要線索，但不是唯一線索，分別見 W3C WAI 的圖片替代文字教學與 Google Images 的最佳做法。

WebAIM 2026 年的數字值得記一下：53.1% 的首頁至少有一張圖片缺少 alt；首頁平均有 66.6 張圖，其中 16.2% 的圖片缺少 alt，平均每頁 10.8 張。在已有替代文字的圖片中，另有 10.8% 的 alt 被判定為可疑或重複，例如只寫「image」、「graphic」、檔名，或與鄰近文字相同。合計超過四分之一的圖片缺少 alt，或 alt 可能有問題、重複（WebAIM Million 2026 年報告）。

寫 alt 有幾個原則，無障礙和 SEO 共用同一套邏輯：

• 描述圖片在當下情境傳達的資訊。複雜圖表可提供簡短 alt，再在正文或相鄰資料表列出完整數據與關係；不要把所有內容塞進一個過長的 alt。
• 裝飾性圖片用空的 alt（alt=""），讓螢幕閱讀器跳過，不要寫「裝飾圖片」。
• 不要把關鍵字塞進 alt。Google 明確建議避免 keyword stuffing；對螢幕閱讀器使用者也是干擾。
• 圖片若是連結或按鈕的唯一內容，替代文字應描述目的或動作。若同一連結已有足夠文字，圖片可能可用空 alt，避免重複朗讀；應以整個控制項的可存取名稱判斷。

有一個細節很多人搞混：alt、圖片檔名與 title 屬性是三件不同的事。Google 表示描述性檔名只提供很輕微的圖片主題線索；title 屬性不是 alt 的替代品，對部分輔助科技也不可靠；alt 才是 <img> 的文字替代內容。想把圖片這塊的 SEO 做得更完整，可以看圖片 SEO 優化指南；alt 的官方立場見 Google Images SEO 最佳做法，無障礙角度可對照 W3C WAI 的 Images Tutorial。

連結、按鈕與表單：描述性文字是雙方的共通貨幣

除了圖片，連結與按鈕的文字描述也是無障礙與 SEO 重疊很深的地方。WebAIM 2026 年的數字（出自 The WebAIM Million）：46.3% 的首頁有空連結，30.6% 有空按鈕，15.2% 有模糊連結文字，例如「點這裡」「更多」「繼續」。

「點這裡」等文字脫離上下文時可能難辨識。Google 建議描述性、簡潔而相關的錨點；WCAG 2.4.4 則容許透過連結文字加上可程式判定的上下文辨識用途，並非每個「了解更多」都自動違規。原則分別見Google 連結最佳做法及W3C SC 2.4.4。

表單的情況類似。WebAIM 發現首頁平均有 6.9 個表單輸入欄位，其中 33.1% 沒有正確標籤；51% 的首頁至少有一個缺少標籤的欄位。正確連結的 <label> 可讓螢幕閱讀器讀出欄位用途，也讓語音輸入使用者用可見標籤操作欄位。自動填入則應搭配符合 WCAG 1.3.5 的 autocomplete 等程式化用途標記，不能只靠 <label> 就保證瀏覽器或密碼管理器一定正確填入；欄位標籤的基礎見 W3C WAI 的〈Labeling Controls〉，程式化用途的要求定義在 SC 1.3.5 的解說，統計背景出自 WebAIM 2026 年報告。

接著要談一個很容易踩錯的方向：ARIA。ARIA（Accessible Rich Internet Applications）是一組補充角色、狀態與屬性，用來讓自訂互動元件對輔助科技有意義。WebAIM 發現，有 ARIA 的頁面平均偵測到 59.1 個錯誤，沒有 ARIA 的頁面平均 42 個；2026 年每個首頁平均有超過 133 個 ARIA 屬性，比 2025 年增加 27%（WebAIM Million 2026 年報告）。

這是相關性，不代表 ARIA 造成那些錯誤。有 ARIA 的頁面也可能本來就更複雜。實作原則仍是：能用原生 HTML，就優先使用原生 HTML。一個 <button> 本身就有按鈕語意與預設鍵盤行為；把 <div> 加上 role="button"，開發者還得自行補上焦點與鍵盤操作。WebAIM 另發現 5.7% 的首頁用了 role="menu"；其中 22% 的選單因缺少必要標記或互動而產生無障礙障礙。ARIA 是進階工具，不是裝飾品；拿不準的時候，退回原生 HTML 通常更安全，這是 W3C WAI 的 Using ARIA 指引的核心提醒，統計同樣出自 WebAIM 2026 年報告。

顏色對比與可讀性：最常見也最容易被忽略的缺陷

低對比文字，是 WebAIM 2026 年自動檢測中最常見的缺陷。83.9% 的首頁有低對比文字，平均每頁 34 處，比 2025 年增加 15%，出自 WebAIM Million 年度報告。

WCAG AA 的最低對比門檻是：一般文字與背景至少 4.5:1；大字至少 3:1。這裡的大字是至少 18 point 的一般字，約 24 CSS px，或至少 14 point 的粗體字，約 18.5 CSS px。門檻另有例外，包括標誌文字、停用控制項內的文字、純裝飾與對所有人都不可見的文字，以及屬於含有其他重要視覺內容之圖片的一部分。門檻定義在 WCAG 1.4.3 Contrast (Minimum)，比值可以用對比檢查工具直接量。

對比是否符合 WCAG 並未被 Google 公開列為獨立排名因素，也沒有可靠官方證據可把停留時間或跳出率直接等同於對比的排名回饋。因此，修對比的直接理由是讓內容可讀、符合無障礙要求，不該包裝成已證實的 SEO 加分技巧。

不過這裡要小心一個誤區。低對比經常不是設計師故意選淡色，而是設計稿在背景圖上壓了白字，到了實際頁面、不同螢幕與環境光下就難以閱讀。修法可以是調整文字或背景顏色、加入足夠不透明度的底色，並用工具重新量測實際呈現結果。不能只憑肉眼覺得「看得到」就當作通過。

鍵盤操作、焦點可見與 INP：互動體驗的雙重收益

鍵盤可操作是無障礙的核心要求之一。部分使用者因為視覺、動作能力或個人偏好，不使用滑鼠，只用鍵盤（Tab、Enter、方向鍵、空白鍵）操作網站。WCAG 2.1.1 要求所有內容功能都能透過鍵盤介面操作，但對底層功能本來就依賴移動路徑的輸入另有例外；鍵盤操作的要求定義在 WCAG 2.1.1 Keyboard，焦點可見則由 2.4.7 Focus Visible 等準則規範。

這一塊跟 SEO 的關係比較間接，但有兩個清楚的交集。

先區分兩項要求：WCAG 2.4.7 關注可見的鍵盤焦點；2.2 新增的 2.4.11 則要求取得焦點的元件不能被作者建立的內容完全遮住。只有不遮住元件，仍不代表焦點指示足夠清楚。

另一個是 INP（Interaction to Next Paint，互動到下次繪製）。INP 衡量頁面對點擊、輕觸與鍵盤互動的整體回應速度；它在 2024 年 3 月 12 日取代 FID，成為 Core Web Vitals 指標。良好門檻是頁面至少 75% 的造訪能達到 200 毫秒以下。這項效能改善會讓不同輸入方式的使用者受益，Google 也把 Core Web Vitals 用於其排名系統，但 Google 明確提醒，好分數不保證排名靠前；INP 的定義與取代 FID 的時程見 web.dev 的 INP 說明與〈INP is now a Core Web Vital〉，排名訊號的定位則出自 Google 搜尋中心。想看 INP 的門檻與修法，可以讀Core Web Vitals SEO 指南。

簡單講，互動流暢度能同時改善一般使用者與鍵盤使用者的體驗，也與 Core Web Vitals 有明確關係；但它不能代替鍵盤可操作性、正確語意或螢幕閱讀器測試。相關的速度優化手法可以參考網站速度優化指南。

行動版與響應式：無障礙與行動優先索引的重疊

行動版體驗是無障礙與 SEO 重疊明顯的地方之一。Google 在 2016 年開始行動優先索引，2019 年 7 月只是對新網站預設啟用，直到 2023 年 10 月才宣布轉換完成。現在 Google 主要用智慧型手機代理程式抓取的行動版內容進行索引與排名；這是一種索引方式，不表示採用響應式設計本身就會得到獨立排名加分，2023 年 10 月的〈Mobile-first indexing has landed〉宣布了轉換完成，實作建議見 Google 的行動版最佳做法。

從無障礙角度看，小螢幕上的可讀性、重排與目標尺寸都很重要，但 WCAG 不強制只能用 responsive design。WCAG 1.4.10 要求內容在相當於 320 CSS px 寬的情境下能重排而不失去資訊或功能，特定二維版面另有例外。WCAG 2.2 的 2.5.8 Target Size (Minimum) 則要求指標輸入的目標至少 24×24 CSS 像素，或符合間距、等效控制、行內目標等例外，分別對應 WCAG 1.4.10 Reflow 與 2.5.8 Target Size (Minimum) 的條文。

把這兩條線拉在一起，你會發現：桌機正常的頁面若在手機上字太小、按鈕太擠、主要內容不完整或必須不必要地橫向捲動，可能同時傷害使用者與 Google 對行動版內容的取得。響應式設計是 Google 推薦且容易維護的做法之一，但不是唯一符合行動優先索引或 WCAG 的技術。這一塊的設計觀念，可以搭配響應式網頁設計與UI 與 UX 的差別一起看。

怎麼檢測：Lighthouse、axe、WAVE 與手動測試的分工

無障礙檢測沒有單一工具能搞定全部，這是要建立的觀念。自動化工具抓得到的是可由規則判斷的缺陷，比如缺 alt、對比不足、缺表單標籤。抓不到或無法完整判斷的是 alt 是否傳達正確資訊、流程是否真的能用鍵盤走完等問題。W3C 沒有提供「所有自動化工具固定只能發現三到四成 WCAG 問題」這種通用比例；工具、規則集、頁面與計算方式不同，比例也會變。W3C 能確認的是：工具無法自動檢查所有無障礙面向，合格判定仍需要人工判斷，不能用單一固定百分比概括，這是〈Selecting Web Accessibility Evaluation Tools〉的立場。

主流工具有幾個，各有定位：

↔ 左右捲動檢視完整表格

工具	類型	擅長	限制
Lighthouse	自動（Chrome 內建）	整合分數、快速掃目前頁面	只涵蓋自動稽核，分數不含所有手動項目
axe / axe-core（Deque）	自動（瀏覽器擴充、CI）	規則檢查、可整合開發流程	只抓規則可自動判斷的問題
WAVE（WebAIM）	自動與輔助評估	視覺化標出缺陷位置與對比	仍需人工解讀與驗證
鍵盤測試	手動	真實驗證鍵盤導覽與焦點	耗時、需要經驗
螢幕閱讀器測試	手動	驗證輔助科技實際體驗	學習曲線高

Lighthouse 的 Accessibility 類別使用 axe-core 執行自動無障礙稽核；分數是各項通過或失敗稽核的加權平均，權重依 axe 的使用者影響評估而定。需要人工檢查或權重為零的項目不計入分數，所以 100 分也不能證明頁面完整符合 WCAG；計分邏輯見 Chrome for Developers 的 Lighthouse Accessibility scoring 說明，權重制度的引入可回溯〈What's new in Lighthouse 6.0〉。

我會建議的檢測順序是：先用 axe 或 Lighthouse 快速掃一遍抓自動可判斷的問題，再用 WAVE 視覺化複查對比與標題，收尾的動作是親自用鍵盤走一次核心流程，確認每個互動都到得了、焦點都看得見。自動化工具是入場券，不是終點；只靠分數判斷無障礙做得多好，一定會漏。

鍵盤測試不需要專業設備，只要有耐心。具體可以照這個迷你清單走一遍：從頁面最上方按 Tab，看焦點是否依合理順序移動；每個互動元件是否都能用適合該元件的鍵盤操作；焦點框是否清楚可見、有沒有被固定元素完全遮住；能否用鍵盤走完整個表單並送出；對話框打開後，焦點是否留在對話框內，能不能用 Esc 關掉並回到原本觸發元件。任何一步卡住，都需要進一步確認是否違反對應準則，也通常代表真人使用者會在這裡遇到阻礙。

台灣情境：法規底線、標章與 Freego 檢測工具

台灣的無障礙網站法規，核心是《身心障礙者權益保障法》第 52-2 條。法條原文規定各級政府及其附屬機關（構）、學校所建置的網站，應通過第一優先等級以上的無障礙檢測，並取得認證標章。現行「網站無障礙規範（110.07）」的標章分成 A、AA、AAA，A 是最低級別。主管機關是數位發展部，現行技術規範以 WCAG 2.1 為基礎；條文可查全國法規資料庫，規範與標章制度分別見「網站無障礙規範（110.07）」與數位發展部的核發辦法。

這裡有幾個台灣特有的點要搞清楚：

• 法條的文字是「第一優先等級以上」；現行標章制度的最低級別標示為 A。第 52-2 條與現行核發辦法沒有把所有適用網站的門檻統一提高到 AA；個別政策或採購案是否加嚴，要看各自文件，不能一概而論。
• Freego 是數發部無障礙網路空間服務網提供的網站檢測工具，可供標章申請前自行檢測，軟體可在數發部網站下載。
• 標章自通過審核日起有效 3 年；網站改版、網頁變動達一定比例或有重大違規等情形，仍可能需要重新申請或被取消，規定詳見數位發展部的標章申請頁。
• 第 52-2 條直接規範的是各級政府及其附屬機關（構）與學校網站，不能據此推論一般民間商業網站一律沒有其他法令、契約或特定產業義務；這些要依網站服務、客群與契約另行判斷。

對台灣的政府與學校站來說，無障礙是法定義務。WebAIM 2026 年調查中，政府類網站平均有 42.4 個可偵測錯誤，比整體平均少 24.4%；教育類平均 48.9 個，少 12.8%。依頂級網域分類，.gov 平均 18.5 個、.edu 23.0 個、.com 56.2 個。這些數字顯示樣本中的政府與教育網站平均錯誤較少，不能據此判定特定網站合格，也不能單由相關性證明是法規造成（WebAIM Million 2026 年報告）。

特別值得台灣讀者警覺的是：在 WebAIM 報告列出的常見頁面語言中，中文首頁平均 136.2 個錯誤，比所有受測頁面的平均值高 142.8%，約為英文頁面 46.0 個的 2.96 倍。這份語言表只列出樣本超過 5,000 頁的常見語言，因此不能改寫成「全球所有語言最差」。報告也沒有判定中文頁面錯誤較多的原因，不能只靠這組數據歸因於 CMS、開發習慣或中文網站生態，這些數字同樣出自 該份 WebAIM 調查。

為什麼現在該投資無障礙：觸及、法規與 AI 答案引擎

無障礙的商業論述，我習慣拆成三個層次。

第一是觸及。WHO 2022 年發布的《Global report on health equity for persons with disabilities》採用 2021 年估計，全球約 13 億人，也就是約 16% 人口，經歷顯著失能。這不是每個網站都能直接換算的流失顧客比例，但足以說明失能不是罕見的邊緣情境。一個連螢幕閱讀器都讀不通的結帳頁面，可能直接排除部分使用者，數字出自 WHO 的〈Global report on health equity for persons with disabilities〉與〈Disability and health〉。

第二是法規風險。美國司法部說明，ADA 對州與地方政府，以及向公眾開放的企業，都可能涵蓋其網站所提供的服務。實際適用範圍要依機構性質、服務與法律要求判斷，詳見美國司法部的網站無障礙指引。

歐盟的 European Accessibility Act 是 Directive (EU) 2019/882。指令在 2019 年生效；會員國須自 2025 年 6 月 28 日起適用轉換後的國內措施，不是 EAA 到這一天才生效。它只涵蓋指令列出的產品與消費者服務，例如電子商務、消費者銀行服務、電子書與部分電子通訊、運輸服務資訊，不是所有數位服務一律納入。EAA 本文採功能性無障礙要求，沒有直接指定「WCAG 2.1 AA」就是所有業者的法定合規基準。第 32 條允許服務提供者至 2030 年 6 月 28 日前，繼續使用其在 2025 年 6 月 28 日前已合法用來提供相似服務的產品；2025 年 6 月 28 日前成立的服務契約則可維持到期，但不得超過該日起 5 年。這不是所有既有服務都能一概延到 2030 年；條文以 EUR-Lex 上的 Directive (EU) 2019/882 為準，政策背景可見歐盟執委會的 European Accessibility Act 專頁。另有適用排除與豁免，例如提供服務的微型企業豁免，不能忽略業者規模與服務類型。台灣廠商是否受影響，要看是否向歐盟消費者提供指令涵蓋的產品或服務，不能只憑「做歐美市場或供應鏈」就下定論。

第三，也是跟 SEO 最相關的：答案引擎。Google 公開文件能支持的是，語意 HTML、可存取的文字與清楚的連結有助於 Google 理解頁面；不能由此證明符合 WCAG 會提高 AI Overviews 或其他 AI 答案的引用率。因此，把無障礙視為有助於內容可解析性的基本工程，是合理的技術推論；把它說成「會被 AI 引用」的既定排名機制，就超過現有證據；能支持的依據是 Google 搜尋中心的入門文件與〈SEO Link Best Practices〉對語意與連結的說明。

要特別提醒的是，沒有任何工具或標記能保證內容進入 AI 答案。無障礙提供的是更清楚、可操作與可解析的頁面，不是一定被選中的門票。結構化資料（schema）也有類似界線：Google 明確表示，正確標記不保證一定顯示 rich result（〈General structured data guidelines〉）。

這三層加起來，無障礙可以擴大可用性、降低部分法規風險，也能改善機器可解析的結構。它不是排名救星，更適合被當成長期工程，而不是一次性專案。

常見誤解

↔ 左右捲動檢視完整表格

誤解	實際情況
無障礙是 Google 排名因素	Google 公開文件未把「符合 WCAG」列為獨立排名系統；語意 HTML、alt、行動版內容與 Core Web Vitals 等各有自己的搜尋用途，不能把它們統稱成無障礙直接加分。
裝一個無障礙外掛就合規	不一定。自動工具無法檢查所有問題；鍵盤導覽、alt 品質與流程可用性仍需人工，外掛無法保證合規。
ARIA 用越多越無障礙	不成立。WebAIM 發現有 ARIA 的頁面平均錯誤較多，但這是相關性而非 ARIA 導致錯誤。原則仍是先用對原生 HTML。
對比只影響視障者	低對比也可能影響在強光、小螢幕或視力退化情境下閱讀的人；是否合格要依 WCAG 比值量測。
台灣要求 AA 等級	第 52-2 條要求第一優先等級以上；現行標章制度最低級別為 A。第 52-2 條與現行核發辦法沒有對全部適用網站統一要求 AA。
無障礙做完一次就永久有效	不是。網站改版、新增頁面與內容變更都可能引入新缺陷，台灣無障礙標章也有 3 年效期。

WCAG 2.1 跟 2.2 差在哪，台灣網站該做哪一個？

2.2 在 2.1 基礎上新增 9 條成功準則、移除過時的 4.1.1 Parsing，並向下相容 2.1。截至 2026 年 9 月 21 日，台灣仍依「網站無障礙規範（110.07）」辦理標章申請，內容以 WCAG 2.1 為基礎；修正版預定 2026 年 11 月 30 日實施。W3C 鼓勵採用目前最新版本，所以新建或改版網站可以直接把 WCAG 2.2 當技術目標；但法律、採購或合約要求仍要按各自指定版本驗收，不能籠統宣稱國際採購都以 2.2 為準，版本演進見 W3C WAI 的 WCAG 2 總覽，台灣的切換時程則以數發部的異動公告為準。

無障礙會直接提升 Google 排名嗎？

沒有證據可把「符合 WCAG」當成獨立的直接排名因素。語意 HTML、alt、行動版內容與互動效能各自可能幫助搜尋引擎理解、索引圖片或評估頁面體驗，但不要期待修完對比就讓排名上升。

自動化檢測通過了，等於無障礙合格嗎？

不等於。W3C 明確說明，工具無法自動檢查所有無障礙面向，判定仍需要人類參與。鍵盤導覽、alt 文字品質、流程邏輯、螢幕閱讀器實際體驗，都需要人工驗證。把自動分數當終點是常見陷阱，〈Selecting Web Accessibility Evaluation Tools〉對工具限制有完整說明。

台灣的民間商業網站需要做無障礙嗎？

《身心障礙者權益保障法》第 52-2 條直接規範的是政府及其附屬機關（構）與學校網站，不是一般民間網站的概括條款。但民間網站仍可能受到其他產業法規、契約、採購規格或服務地法規影響。若向歐盟消費者提供 EAA 涵蓋的產品或服務，也要依適用範圍評估，不能只看公司設立地。

結構化資料（schema）跟無障礙有關係嗎？

兩者目的不同。結構化資料用機器可讀格式描述頁面實體與內容類型；無障礙則讓內容與操作對身心障礙使用者及輔助科技可用。它們都可能使用 HTML 標記，但做好其中一項不代表另一項自然合格。想把結構化資料這塊補起來，可以接著讀結構化資料標記指南。

結論與下週就能執行的行動清單

回到開場那句話：無障礙跟 SEO 是兩件事，但交集很大。把交集區（語意 HTML、標題層級、alt、連結文字、行動版內容、INP）做好，你同時改善了人的使用體驗與機器可取得的結構。把交集之外的部分（對比、焦點可見、鍵盤流程）當成對人友善與符合規範的長期投資，不期待它直接拉升排名。這樣分配資源，才不會把無障礙誤當成排名捷徑，也不會因為它不是獨立排名因素就完全不做。

下週就能執行的三件事：

• 使用 Tab、Shift+Tab、Enter、空白鍵與元件適用的方向鍵，走完核心流程。記錄焦點順序、指示、陷阱及表單問題，再用合適的螢幕閱讀器做人工驗證。
• 用 Lighthouse 或 axe 跑一遍你流量最大的五個頁面，把自動工具找到的問題列成清單。WebAIM 2026 年發現，低對比、缺 alt、缺表單標籤、空連結、空按鈕與缺文件語言這六類合計占所有偵測錯誤的 96%，可優先從這些高頻類型處理（WebAIM Million 2026 年報告）。
• 檢查你的圖片 alt：資訊圖片有沒有能傳達同等目的的文字替代、裝飾圖片是不是用空的 alt、有沒有把關鍵字塞進去的垃圾 alt。這一項同時幫無障礙與圖片理解，值得優先處理。

無障礙不是一次做完就結束的專案，它跟 SEO 一樣是持續工程。網站每次改版、加功能或換內容，都可能引入新缺陷。把自動檢查放進開發流程，再定期做鍵盤與輔助科技人工測試，會比追求一次性的漂亮分數可靠。