網站無障礙設計怎麼做？WCAG 重點、八個常見問題與覆蓋層爭議

這篇要處理的是一個很多自架站主與接案者都知道「應該做」、但一直沒動手的題目：網站無障礙設計。原因通常不是不想做，而是資訊太亂——有人說台灣政府強制、有人說民間網站也會被告、有人說裝一個外掛就搞定、有人說裝了那個外掛反而更糟。這些說法彼此矛盾，於是大家索性擱著。

讀完這篇，你會拿到四件具體的東西。第一，WCAG 2.2 的 A、AA、AAA 三個等級到底差在哪、你該挑哪一級，以及 2.2 相對 2.1 多了什麼。第二，台灣「無障礙網頁標章」的現行規範、現在的主管機關是誰，以及最關鍵的一題：純民間的商業網站到底有沒有法律強制義務（我把法條原文查了，答案比你想的乾脆）。第三，最常見也最好修的八個問題，每一個都附上 WordPress 上的具體做法。第四，為什麼「無障礙覆蓋層外掛」在身障社群裡幾乎是負面詞，以及美國聯邦貿易委員會對其中一家業者開出的罰則。

先講一個會讓你比較有動力的數字。WebAIM 每年掃描全球前一百萬個網站首頁，2026 年 2 月那一輪的結果是：95.9% 的首頁存在可被自動偵測到的 WCAG 2 失敗，平均每頁 56.1 個錯誤，而且這個比例比 2025 年的 94.8% 還往上跳了一格。更值得台灣站主注意的是語言別的差異——以中文為主要語言的首頁，平均每頁 136.2 個錯誤，比全體平均高出 142.8%，是所有語言中最差的一組（資料來源：WebAIM Million 2026 報告）。也就是說，這件事的競爭門檻其實非常低。

另外先聲明：本文整理的是公開法規與官方文件，不構成法律意見。真的碰到爭議或要簽跨境合約，請找執業律師確認。

先講結論：你的網站到底該做到什麼程度

把身分先分清楚，後面的每一段才有意義。無障礙這件事在台灣的義務強度，取決於「你是誰」與「你的客戶是誰」，而不是「你的網站有多大」。

你的情境	法律上是否強制	實務上該做到
政府機關、公立學校自己的網站	是。身心障礙者權益保障法第 52 條之 2 明文	依現行「網站無障礙規範」通過檢測並取得標章
接案者承接政府機關網站標案	間接強制。義務主體是機關，但會寫進你的契約與驗收條件	報價與工期一開始就把檢測、修正、複測算進去
純民間的部落格、電商、公司官網（客戶都在台灣）	查無普遍性強制規定	自願做到 WCAG 2.2 AA 的大部分項目，成本低、回收快
向歐盟消費者提供電子商務服務	是。歐盟無障礙法自 2025 年 6 月 28 日起適用，微型企業提供服務者有豁免	把無障礙需求納入產品規格，不是上線後補
幫美國州政府、地方政府做網站	是。美國司法部規則指定 WCAG 2.1 AA	依對方遵循期限倒推排程

看出來了嗎。台灣的法規把義務綁在「政府與學校」上，民間網站沒有一條普遍適用的強制規定。但如果你是接案者，你會發現自己幾乎一定會碰到——因為政府標案是台灣網頁接案市場很大的一塊，而且合約裡的無障礙條款通常寫得比你想像的硬。這件事應該在網頁設計報價單的欄位結構裡就先列成一條，而不是驗收前才發現多了兩週工期。

還有一個角度值得先講：無障礙做得好的網站，通常同時是體驗好、結構乾淨、SEO 基礎穩的網站。替代文字、標題階層、有意義的連結文字這三件事，本來就同時是無障礙需求與 SEO 的基本面。這不是「順便」，是同一批工作換個名字。

WCAG 2.2 的 A、AA、AAA 到底差在哪

先確認你看的是不是現行版本

這一步很多文章跳過，然後整篇建立在舊版上。W3C 的《Web Content Accessibility Guidelines (WCAG) 2.2》目前是 W3C Recommendation（正式建議標準），最初發布日是 2023 年 10 月 5 日，而現行版本的發布日期是 2024 年 12 月 12 日（見 W3C WCAG 2.2 全文頁首的版本標示）。這代表你如果在 2023 年底看過一次 2.2，內容其實已經被修訂過一輪。

下一代的 WCAG 3.0 呢？截至本文查證時，它仍然是 W3C Working Draft（工作草案），最新一版標示為 2026 年 3 月 3 日（W3C WCAG 3.0 草案）。草案的意思是：架構還會變、條文還會增刪，任何人現在跟你說「要準備 WCAG 3.0 合規」都是超前太多。你現在要做的仍然是 2.2，而且大部分法規指定的還是更早的 2.1。

三個等級的定義，以及各有幾條

WCAG 的結構是四層：四大原則（可感知、可操作、可理解、穩健性）之下有指引，指引之下是「成功準則」，每一條成功準則被標記為 A、AA 或 AAA 其中一級。等級不是「難度」，而是「影響範圍」。W3C 的原文說明是：三個等級的設立，是為了對應不同族群與不同情境的需求。

• Level A：最低門檻。沒做到，某些使用者或族群根本無法使用你的網站。例如圖片完全沒有替代文字、影片完全沒有字幕、功能只能用滑鼠觸發。
• Level AA：業界與各國法規的實質標準線。沒做到，某些使用者會遇到明顯困難，但不至於完全卡死。對比度不足、缺少可見的焦點樣式、標題結構混亂都屬於這一層。
• Level AAA：加強級。W3C 自己在文件中就說明，AAA 並不適合作為整站的通用政策目標，因為部分內容型態根本不可能滿足所有 AAA 準則。例如 AAA 要求本文對比度 7:1、要求預錄影片提供手語翻譯，這對一般部落格是不切實際的。

條文數量方面，我直接以 W3C 官方全文中每一條成功準則標註的等級逐條計數，結果是：Level A 有 31 條、Level AA 有 24 條、Level AAA 有 31 條，合計 86 條。如果你要對外承諾「符合 WCAG 2.2 AA」，你要滿足的是 A 加 AA 共 55 條，而不是只有 24 條——這是很常見的誤解，AA 的定義是「同時滿足 A 與 AA」。

為什麼所有人都停在 AA

因為 AA 是投入報酬率的轉折點。從零到 A，你解決的是「完全不能用」；從 A 到 AA，你解決的是「用起來很痛苦」；從 AA 到 AAA，你解決的是「已經能用，但可以更好」，而成本卻是前兩段的好幾倍。

更現實的是，各國法規幾乎一致停在 AA。美國司法部針對州與地方政府網站的規則指定的技術標準是 WCAG 2.1 Level AA；台灣現行的網站無障礙規範也是用 A、AA、AAA 三個檢測等級，而政府機關網站的法定底線是「第一優先等級以上」。WordPress 官方的無障礙編碼標準同樣寫得很明確：整合進 WordPress 生態系的程式碼（包含核心、WordPress.org 網站與官方外掛）應符合 WCAG 2.2 的 AA 等級，AAA 則是「鼓勵在相關情境下達成」（WordPress 無障礙編碼標準）。

所以實務建議很單純：把 AA 當目標，把 AAA 當選配。有幾條 AAA 其實很便宜（例如提供多種找內容的方式、避免只用顏色傳達狀態的延伸做法），順手做掉就好，但不要把 AAA 寫進合約承諾。

WCAG 2.2 比 2.1 多了什麼

2.2 新增了九條成功準則，並移除了一條。新增的九條集中在「操作」與「輸入」兩個痛點上，而且非常貼近現代網站的實際毛病：

編號	名稱	等級	白話說明
2.4.11	Focus Not Obscured (Minimum)	AA	用鍵盤 Tab 移動時，取得焦點的元件不可以被固定式頁首、Cookie 橫幅、浮動客服窗完全遮住
2.4.12	Focus Not Obscured (Enhanced)	AAA	同上，但要求完全不被遮住
2.4.13	Focus Appearance	AAA	焦點外框的面積與對比要達到一定標準
2.5.7	Dragging Movements	AA	凡是需要拖曳的操作，都要提供不用拖曳的替代方式（例如上下箭頭按鈕）
2.5.8	Target Size (Minimum)	AA	可點擊目標要有最小尺寸，避免小圖示擠在一起
3.2.6	Consistent Help	A	如果多個頁面都有客服、聯絡方式或說明，位置要一致
3.3.7	Redundant Entry	A	同一流程中已填過的資訊，不應要求使用者再填一次
3.3.8	Accessible Authentication (Minimum)	AA	登入不應強迫使用者「靠記憶」通關，例如不能只提供需辨識扭曲文字的驗證方式，且不應阻擋密碼貼上
3.3.9	Accessible Authentication (Enhanced)	AAA	同上，限制更嚴

被移除的那一條是 4.1.1 Parsing。W3C 直接在 2.2 的文件中說明這條已經過時（obsolete）並自 2.2 移除，理由是現代瀏覽器與輔助科技對於重複 ID、標籤未閉合這類 HTML 錯誤的處理已經成熟，這條準則不再對應真實的使用者障礙。這一點值得記住，因為市面上不少檢測工具與教學文章還在把「重複 ID」列為 WCAG 失敗。它現在是程式碼品質問題，不是無障礙合規問題。

另外提醒兩條特別容易被自架站踩到的：3.3.8 的「不應阻擋密碼貼上」，很多會員系統為了「安全」把密碼欄的貼上功能鎖掉，這在 2.2 之後是明確的 AA 失敗；2.4.11 的焦點遮蔽，只要你裝了黏性頁首外掛又沒調整 scroll-padding-top，幾乎必然中招。

台灣的無障礙網頁標章：誰強制、誰自願

法源長什麼樣子

台灣的無障礙網頁義務，法源在《身心障礙者權益保障法》第 52 條之 2。這條的現行條文只有兩項，短到可以整條抄：

各級政府及其附屬機關（構）、學校所建置之網站，應通過第一優先等級以上之無障礙檢測，並取得認證標章。

前項檢測標準、方式、頻率與認證標章核發辦法，由目的事業主管機關定之。

（條文取自全國法規資料庫「身心障礙者權益保障法」所有條文頁，該頁標示的修正日期為民國 114 年 8 月 1 日。這裡要提醒一個查法條的坑：全國法規資料庫的「單條」頁面預設顯示的是最新公布版，不一定等於現行有效版，查法條時請用「所有條文」頁交叉比對。）

請注意主詞：各級政府及其附屬機關（構）、學校。整條沒有一個字提到民間企業、個人網站或商業網站。

主管機關已經不是 NCC，也不是國發會

這是網路上過期資訊最多的一段。依第 52 條之 2 第 2 項授權訂定的法規命令，現行名稱是《各級機關機構學校網站無障礙檢測及認證標章核發辦法》，現行版本修正日期為民國 112 年 2 月 14 日。其中第 2 條寫得非常清楚：

本辦法所稱主管機關為數位發展部。

也就是說，無障礙網頁標章的主管機關是數位發展部（moda），不是國家通訊傳播委員會，也不是國家發展委員會。相對應地，「無障礙網路空間服務網」的網域也已經從 accessibility.ncc.gov.tw 換成 accessibility.moda.gov.tw——我在查證時測試舊網域，已經無法建立連線。如果你看到一篇教學還在叫你去 NCC 申請標章，那篇文章至少過期兩年以上，其他內容也建議一併打折。

這份辦法還有幾條對接案者很有用的細節（辦法全文在此）：

• 第 4 條：各機關應自行檢測其資訊服務網站的無障礙功能並向主管機關辦理註冊，再備具申請書與自行檢測報告申請核發標章。也就是說，流程設計上是「機關自己送件」，承包廠商不是申請人。
• 第 5 條：標章有效期間三年。這代表標案結束不等於事情結束，三年後要重新來過，這是接案者可以規劃的續約點。
• 第 6 條：標章尺寸規格為寬 88 像素、高 31 像素，張貼時不得變更尺寸、變形或加註字樣，並須連結至主管機關指定的網頁，位置在網站首頁下方。很多網站被退件就是因為設計師把標章「調整成比較好看的大小」。
• 第 7 條：主管機關可以抽測已張貼標章的網站，未通過會限期改正，屆期未改正就廢止並註銷標章且公告。抽測比率規定為每年應達前一年度已核發標章數的 5% 以上，而且抽測作業應有身心障礙者參與。

現行規範是「網站無障礙規範(110.07)」，對應的是 WCAG 2.1

標章要檢測什麼，看的是主管機關訂的《網站無障礙規範》。現行版本是「網站無障礙規範(110.07)」，也就是民國 110 年 7 月版；舊的「網站無障礙規範 2.0 版」已經退場，官方頁面上標註為典藏參考用，對應的舊版 Freego 2.0 檢測工具也已註明不再受理申請。

依照官方說明頁的內容，110.07 版的架構是：延續 2.0 版的條文架構，新增 1 個指引、修改 1 個指引、新增 17 個成功準則與 48 個稽核評量碼，整體形成 13 指引、78 成功準則，並以 3 個檢測等級（A、AA、AAA） 區分（資料來源：無障礙網路空間服務網「網站無障礙規範(110.07)」）。四大原則的用語與 WCAG 完全對應：可感知、可操作、可理解、穩健性。

版本對應關係要講清楚：2017 年實施的 2.0 版對應的是 WCAG 2.0，110.07 版則是為了納入 WCAG 2.1 的行動裝置相關條文而做的更新。官方前言明確提到 WAI 於 2018 年 6 月 5 日公布 WCAG 2.1，內容加入行動版網頁條文，讓無障礙規範從桌機瀏覽邁向手機與平板。所以台灣的檢測基準目前對齊到 WCAG 2.1，還沒對齊到 2.2。

這帶出一個實務上的取捨：如果你做的是政府標案，交付標準以 110.07 規範與 Freego 檢測報告為準；但如果你在做自己的站或民間客戶的站，直接對著 WCAG 2.2 AA 做就好，因為 2.2 是 2.1 的超集合，做到 2.2 自然涵蓋 2.1。

民間網站到底有沒有強制？

我把上述兩份法規全文都讀過，結論是：目前台灣沒有一條普遍性規定，強制純民間、非政府補助的商業網站必須符合無障礙規範或取得標章。身心障礙者權益保障法第 52 條之 2 的義務主體是各級政府、附屬機關（構）與學校；依其授權訂定的辦法，名稱本身就叫「各級機關機構學校網站無障礙檢測及認證標章核發辦法」，第 4 條的主詞同樣是「各級政府及其附屬機關（構）、學校（以下簡稱各機關）」。

我沒有查到針對民間網站的一般性罰則或強制條款。這裡我選擇誠實停在這裡：查無明文，就不推測。網路上有些文章會暗示「台灣民間網站也可能因為身權法被裁罰」，但沒有指出具體條號；在找到具體條文之前，把它當成未證實的說法比較安全。

不過「沒有普遍強制」不等於「永遠不會被要求」。下列情境是民間網站實際上會被要求做無障礙的：

1. 承接政府機關或公立學校的網站標案。義務主體是機關，但機關會把要求轉寫進招標規範與驗收條件，包含檢測等級、Freego 報告、標章申請協助。這是台灣接案者最常遇到的情境。
2. 接受政府補助或委辦而建置的網站。補助契約通常會把無障礙列為交付條件之一，實際條款依各機關的補助要點而定，簽約前務必逐條看。
3. 向歐盟或美國市場提供服務。這一段下面單獨講，因為對做跨境電商與服務海外客戶的接案者影響最直接。
4. 自願申請標章。民間單位是可以申請的。標章申請頁面明確寫著：機關名稱請透過查詢機關代碼選取，無機關代碼者請選擇「民間團體」；政府機關須以「我的 E 政府會員之公務帳號」提出申請，民間團體則可用 E 政府會員或該站會員申請（見標章申請頁面）。對做無障礙相關、社福相關、教育相關業務的民間單位，這個標章是有說服力的信任訊號。

跨境接案：把無障礙寫進合約之前要先搞懂的兩套法

歐盟：European Accessibility Act 已經在跑了

歐盟的 Directive (EU) 2019/882，一般稱為 European Accessibility Act（歐洲無障礙法）。關鍵日期是：該指令適用於 2025 年 6 月 28 日之後投放市場的產品，以及該日之後提供給消費者的服務。也就是說，它不是未來式，是已經生效一年的現在進行式。

涵蓋範圍包含電腦與作業系統、自動櫃員機與售票機、智慧型手機、數位電視設備、電話服務、視聽媒體服務、空運鐵路公路與水運客運服務、消費者銀行服務、電子書，以及電子商務。電子商務是明確列入的。指令對「電子商務服務」的定義是：透過網站或行動裝置服務、以電子方式、在消費者個別請求下遠距提供，並以締結消費者契約為目的的服務。

豁免規定要看清楚：提供服務的微型企業免除服務類無障礙要求。而微型企業的定義是「雇用人數少於 10 人，且年營業額不超過 200 萬歐元，或年度資產負債表總額不超過 200 萬歐元」（指令全文見 EUR-Lex；歐盟執委會的政策說明頁在這裡）。台灣多數一人接案與小型工作室在人數與營業額上都落在微型企業的範圍內，但這個豁免保護的是「你自己的服務」，不代表你幫歐盟客戶做的網站可以不合規——那是客戶的義務，而且會透過合約落到你身上。

至於「非歐盟境內的業者，向歐盟消費者提供服務是否適用」，指令文本並沒有用一句話直接回答這個問題，實務上會涉及各成員國的轉換立法與執法認定。這一題我不編答案：如果你的客戶是歐盟公司或你的電商大量出貨到歐盟，請直接請客戶的法務給你合規規格書，不要自己推測。

美國：Title II 有明文標準，Title III 沒有

美國司法部在 2024 年 4 月 24 日於聯邦公報發布 ADA Title II 的最終規則，針對州政府與地方政府的網頁內容與行動應用程式訂定技術標準，指定的標準是 WCAG 2.1 Level AA。

遵循期限有過變動，這正是「連結打得開、內容也完整，但版本是舊的」最容易騙人的地方。依 ada.gov 現行的規則說明頁：司法部於 2026 年 4 月 20 日在聯邦公報發布過渡性最終規則（Interim Final Rule），將人口總數 5 萬以上的州與地方政府機關的遵循日展延至 2027 年 4 月 26 日；人口總數不足 5 萬的公共機關，以及任何特別區政府，展延至 2028 年 4 月 26 日（ada.gov 規則說明頁）。如果你手上有美國政府單位的案子，請直接以這兩個日期倒推排程。

要特別分清楚的是：這項規則適用的是 Title II，也就是州與地方政府，官方說明頁自己就寫「跟 Title II 的其他部分一樣，本規則適用於所有州與地方政府」。民間營業場所適用的是 Title III，而 Title III 目前並沒有像 Title II 這樣的網站技術標準規則。我在這裡不對 Title III 的訴訟風險下定論，因為那牽涉判例與各巡迴法院見解，超出「查官方頁面」能確認的範圍。

對接案者的實務結論很單純：把無障礙標準寫成可驗收的規格，而不是形容詞。合約裡不要寫「網站需符合無障礙標準」，要寫「網站需符合 WCAG 2.2 Level AA，以 axe DevTools 與人工鍵盤測試為驗收依據，第三方外掛與客戶自行上傳之內容不在保固範圍」。這種寫法會直接影響你的驗收與尾款，接案合約裡的驗收條款怎麼寫是同一件事的另一半。

最常見也最好修的八個問題

接下來這八項，涵蓋了絕大多數自架站的實際失敗。挑選依據不是我的主觀，而是 WebAIM 2026 年掃描一百萬個首頁的結果——他們統計出的六類最常見錯誤，就占了所有偵測到錯誤的 96%，而且這六類已經連續七年是同一批。我在那六類之外，補上焦點樣式與動畫兩項，因為這兩項在 WCAG 2.2 之後變得更關鍵。

一、圖片的替代文字（alt）

WebAIM 2026 的數據：53.1% 的首頁有圖片缺少替代文字；全體樣本中 16.2% 的圖片沒有 alt（不計 alt="" 的情況），換算下來每頁平均有 10.8 張缺 alt 的圖片（每頁平均圖片總數則是 66.6 張）。更麻煩的是，缺 alt 的圖片有 45% 是被包在連結裡的，這會直接產生「一個沒有任何文字的連結」，螢幕閱讀器只能念出網址。另外有 10.8% 的圖片雖然有 alt，但內容是可疑或重複的，例如寫 image、graphic、blank，或直接是檔名。

正確的寫法只有三個判斷：

• 傳達資訊的圖：用一句話寫出這張圖在這個位置的意思，而不是描述像素。產品圖寫「藍色亞麻長袖襯衫正面」，不要寫「產品圖片」。
• 純裝飾的圖：寫 alt=""（空字串，不是不寫 alt 屬性）。空 alt 會讓螢幕閱讀器直接跳過；沒有 alt 屬性則會讓它去念檔名。
• 圖片是連結或按鈕：alt 要寫「這個連結會帶我去哪」，不是描述圖片。網站 logo 連回首頁，alt 寫品牌名稱就好，不用寫「公司標誌圖片」。

WordPress 上的具體做法：媒體庫每一張圖都有「替代文字」欄位，但媒體庫的 alt 只是插入新圖時的預設值，改了不會回頭影響已經插入文章的舊圖。要批次檢查已發布內容，最實際的方式是用瀏覽器開發者工具在頁面上跑一次選擇器，把所有沒有 alt 屬性的圖片抓出來。另外提醒一個常見誤解：圖片說明（caption）不會取代 alt，兩個欄位服務的是不同的使用者。

二、對比度

這是排名第一的問題，而且差距很大：83.9% 的首頁有低對比文字，平均每頁 34 處，比 2025 年的 79.1% 還惡化。原因通常是設計端的審美偏好——淺灰字配白底看起來清爽，但在陽光下的手機螢幕上根本讀不到。

WCAG 2.2 的門檻整理如下（數值取自 W3C 全文對應條文）：

成功準則	等級	要求
1.4.3 對比（最低）	AA	文字與背景至少 4.5:1；大型文字至少 3:1
1.4.6 對比（增強）	AAA	文字至少 7:1；大型文字至少 4.5:1
1.4.11 非文字對比	AA	使用者介面元件與辨識所需的視覺資訊，與相鄰顏色至少 3:1

「大型文字」的定義是關鍵，很多人以為 20px 就算大字。W3C 的定義是：至少 18 point，或 14 point 且為粗體，或對中文、日文、韓文（CJK）字型而言能產生等效尺寸的字級。W3C 在說明中提到，對多數主流本文字型而言，14 與 18 point 大致相當於 1.2em 與 1.5em（在本文字型為 100% 的前提下），但作者仍須就實際使用的字型自行確認。也就是說中文字型沒有一個固定換算值，要自己量。

另外 1.4.11 常被忽略：輸入框的邊框、切換開關、圖示按鈕、圖表中用來辨識資料的顏色，都要對相鄰色達到 3:1。淺灰邊框的表單欄位是自架站最常見的違規點。

檢查工具用 WebAIM 對比度檢查器最快，貼兩個色碼就會直接告訴你 AA 與 AAA 是否通過。Chrome 開發者工具的檢色器也會直接顯示對比值與通過門檻的參考線。

三、鍵盤操作

判斷方法只有一個，而且不用任何工具：把滑鼠推到一邊，只用 Tab、Shift+Tab、Enter、空白鍵、方向鍵，從頁面最上面走到最下面，完成一次你網站最重要的任務。如果是電商，就走完加入購物車到結帳；如果是部落格，就走完搜尋、開文章、訂閱電子報。

你會遇到的典型失敗：

• 焦點消失：按了幾次 Tab 之後不知道現在在哪裡，通常是主題把 outline: none 寫死了。
• 鍵盤陷阱：進了燈箱或彈窗之後 Tab 出不來，只能重新整理。這是 Level A 的失敗（2.1.2 無鍵盤陷阱）。
• 下拉選單打不開：主選單用 CSS 的 :hover 展開子選單，鍵盤使用者永遠打不開。
• 假按鈕：用 <div> 或 <span> 加 JavaScript 做的按鈕，Tab 根本不會停在上面。原生的 <button> 與 <a> 免費送你鍵盤可及性，自己造輪子就要自己補 tabindex、鍵盤事件與 ARIA 角色。
• Tab 順序跳來跳去：視覺順序與 DOM 順序不一致，多半是版面用絕對定位或 flex 的 order 重排造成的。

順帶一提，跳至主要內容的「跳過連結」（skip link）也屬於這一類。WebAIM 2026 的數據是只有 17.1% 的首頁有跳過連結，而且其中每十個就有一個是壞的——不是被藏到根本無法取得焦點，就是目標錨點不存在。台灣的政府網站常見的「:::」符號就是同一個東西的在地版本，稱為網頁導盲磚，用來標示區塊起點供輔助工具跳轉。

四、焦點樣式

這一項單獨拉出來講，因為它是最常被設計師刻意破壞的無障礙功能。瀏覽器預設的焦點外框確實不好看，於是很多主題直接寫 *:focus { outline: none; }，然後什麼都沒補上。

正確做法不是「不要移除」，而是移除之後要換上更好看的替代品。現代寫法用 :focus-visible，它只會在鍵盤操作時顯示焦點樣式，滑鼠點擊時不顯示，同時解決了美觀與可用性。搭配 outline-offset 讓外框離元件一點距離，視覺上會乾淨很多。

WCAG 2.2 之後還多一層要求：2.4.11 Focus Not Obscured (Minimum)，AA 等級。取得焦點的元件不能被其他內容完全遮蔽。實務上最常出事的是三種東西：黏性頁首、Cookie 同意橫幅、右下角的浮動客服按鈕。黏性頁首的修法很簡單，在 CSS 加上 scroll-padding-top，數值設成頁首高度，瀏覽器捲動到焦點元件時就會自動留出空間。

五、表單標籤

WebAIM 2026 的數據：51% 的首頁有表單欄位缺少標籤，而且全體表單輸入中有 33.1% 沒有透過 <label>、aria-label、aria-labelledby 或 title 正確標記。每頁平均表單欄位數在三年內成長了 36%，這個問題只會越來越嚴重。

最常見的錯誤是用 placeholder 當標籤。placeholder 有三個致命問題：使用者一開始打字它就消失、對比度通常不足、部分螢幕閱讀器不會念。第二常見的錯誤是用 CSS 把 label 藏起來時用了 display: none 或 visibility: hidden——這兩種寫法會讓輔助科技也讀不到。要視覺上隱藏但保留給螢幕閱讀器，要用「視覺隱藏」的 CSS 技巧（絕對定位到 1 像素的裁切區塊），WordPress 主題常見的 .screen-reader-text 類別就是這種寫法。

另外三件常被漏掉的事：錯誤訊息要跟欄位關聯起來（用 aria-describedby 指向錯誤訊息的 id），不要只把欄位框變紅；必填不能只靠紅色星號，要有 required 屬性；錯誤訊息要說怎麼改，寫「格式錯誤」沒有用，要寫「電話請填 10 碼數字，不含符號」。

六、標題階層

標題是螢幕閱讀器使用者最主要的導覽方式，功能相當於明眼使用者的視覺掃描。WebAIM 2026 統計到將近三千萬個標題，平均每頁 29.9 個，一年增加 20.4%；其中 <h6> 的數量一年內翻了一倍以上，而且有至少一個 h6 的首頁裡，94.9% 同時存在跳階的標題層級。

規則其實只有三條：每頁一個 h1、層級不跳號、標題只用來標示結構不用來調字級。第三條是最常被違反的——因為 h4 的字比較小，所以拿 h4 當小標；因為 h2 太大，所以內文小節用 h3 開頭卻沒有 h2。這在頁面編輯器裡特別容易發生，用 Elementor 這類頁面編輯器排版時，標題元件的 HTML 標籤與字級是兩個獨立設定，很多人只調字級沒調標籤，或反過來為了字級去改標籤。正確做法是：標籤依結構選，字級用樣式調。

檢查方式最簡單的是裝一個標題結構檢視的瀏覽器擴充功能，或直接在開發者工具的主控台列出頁面上所有 h1 到 h6 的文字與層級，一眼就看得出哪裡跳號。

七、動畫要能停下來

自動播放的輪播、無限滾動的跑馬燈、進場動畫、視差捲動——這些對前庭功能敏感的使用者會直接引發不適，對認知或閱讀障礙的使用者則會讓內容根本讀不完。

WCAG 的要求分兩層。2.2.2 暫停、停止、隱藏（Level A）：任何自動開始、持續超過 5 秒、且與其他內容並列的移動或閃爍資訊，都必須提供暫停、停止或隱藏的機制。2.3.1 閃爍三次（Level A）：任何內容一秒內閃爍不得超過三次。

現代做法還要加上一層：尊重系統偏好。作業系統與瀏覽器都提供「減少動態效果」的設定，CSS 用 @media (prefers-reduced-motion: reduce) 就能偵測，在這個區塊裡把動畫時長設成極短或直接關閉。這是幾行 CSS 的事，卻是很少有台灣網站做的。

WordPress 上的處理順序建議是：先關掉首頁大圖輪播的自動播放（改成手動切換或直接換成單張大圖，順便改善載入速度），再處理進場動畫。多數頁面編輯器的動畫設定藏在每個區塊的「動態效果」分頁裡，得一個一個關。

八、連結文字要有意義

螢幕閱讀器使用者常用的操作之一，是叫出整頁的連結清單快速掃描。如果你的頁面上有八個「閱讀更多」、五個「點這裡」，那份清單對他們毫無用處。

WebAIM 2026 的數據：15.2% 的首頁有語意不明的連結文字，平均每頁 5.3 處；另外 46.3% 的首頁有空連結（連結內完全沒有可讀文字，通常是包了一張沒 alt 的圖或一個純圖示），30.6% 有空按鈕。

修法：連結文字要能單獨成立。「閱讀更多」改成「閱讀完整的自架站成本試算」；圖示按鈕加上 aria-label；社群圖示連結不要只放 SVG，要補上「在 Facebook 上追蹤（另開新視窗）」這類文字。順帶一提，這一項跟 SEO 的錨文字最佳實務完全重疊，做一次兩邊都受益。

WordPress 上的踩雷點

佈景主題：accessibility-ready 不等於 WCAG AA

WordPress 官方佈景主題目錄有一個 accessibility-ready 標籤，通過人工審查的主題才能掛。這個標籤有價值，但它的意義被高估了。WordPress 主題審查手冊自己寫得很白：

Accessibility Ready 並不代表該主題達到 WCAG 的 AA 等級。它代表的是該主題達到了主題審查團隊所訂的最低標準。

（出處：Make WordPress Themes 手冊的無障礙章節。）

另一件值得知道的事：這套需求在 2026 年 5 月 6 日做過一次大改版，把原本混在一起的「要求」與「建議」拆開、只保留要求，並新增五項——支援 reflow、縮放與文字間距調整（官方列為同一項）、不得有非預期的情境變更、hover 或 focus 時出現的內容必須可及、必須提供無障礙聲明，以及不得推薦或要求使用不可及的外掛。既有的 accessibility-ready 主題有過渡期，官方公告給主題作者的重測期限是 2026 年 6 月 30 日。官方在公告中提到，原始需求是 2011 年寫的，那時候 WCAG 2.1 與 2.2 都還沒發布、HTML5 與 ARIA 也還沒普及。最後這一項對站主的意義是：主題作者現在有義務不把你導向會破壞無障礙的外掛。

選主題的實務建議：accessibility-ready 標籤當作及格線，不當作終點線。挑完之後仍然要自己跑鍵盤測試與對比度檢查，尤其是主題示範網站上那些漂亮的淺灰小字。挑選邏輯與速度考量可以一起看佈景主題怎麼選的取捨清單。

外掛：越多互動元件，錯誤越多

WebAIM 2026 的技術別統計很值得一看，因為它把「用了什麼」跟「平均錯誤數」放在一起比。以 WordPress 為例，樣本中有 252,302 個首頁使用 WordPress，平均 52.8 個錯誤，比全體平均低 5.8%——也就是說 WordPress 站的表現其實略優於平均，這跟很多人的印象相反。

真正的問題出在疊上去的 JavaScript 函式庫。同一份報告裡，這些常見函式庫全部與較高的錯誤數相關：

函式庫	平均錯誤數	與全體平均差異
Slider Revolution	67.2	+19.8%
Lightbox	70.5	+25.7%
OWL Carousel	70.7	+26.1%
Slick	70.9	+26.4%
Swiper	74.0	+31.8%
jQuery UI	79.9	+42.3%
FancyBox	90.0	+60.3%

報告本身也提醒：這些關聯不必然代表該技術「造成」了錯誤，用這些東西的頁面通常本身就比較複雜。但方向很清楚——輪播、燈箱、彈窗、複雜選單，就是無障礙問題的溫床。這跟把外掛精簡下來的取捨是同一個方向的工作：拿掉一個輪播，速度、無障礙、維護成本三邊同時改善。

ARIA 用越多，錯越多

這是 2026 年報告裡最反直覺、也最值得自架站主記住的一段。全樣本偵測到超過 1.33 億個 ARIA 屬性，平均每頁 133 個以上，一年增加 27%，是 2019 年的六倍以上。而結果是：有使用 ARIA 的首頁平均 59.1 個錯誤，沒有使用 ARIA 的首頁平均 42 個。ARIA 用得越多，偵測到的錯誤通常越多。

另一個具體數字：5.7% 的首頁使用了 role="menu"，而其中 22% 因為缺少必要的 ARIA 選單標記與互動而製造了新的障礙。

結論不是「不要用 ARIA」，而是那句在無障礙圈流傳很久的原則：沒有 ARIA 比錯的 ARIA 好。優先用語意化的原生 HTML——需要按鈕就用 <button>、需要導覽就用 <nav>、需要主要內容區塊就用 <main>。順帶一提，WebAIM 2026 顯示只有 46.1% 的首頁有 <main> 元素或 main 地標，這是一行 HTML 就能補上的東西。

中文站的額外幾個坑

前面提過中文首頁平均 136.2 個錯誤、比全體平均高 142.8%，是所有語言中最高的。從實務經驗看，中文站有幾個特有的問題：

• 頁面語言標記錯誤或缺漏。WebAIM 統計「未指定語言」的頁面平均 60.3 個錯誤，高於平均 7.5%。WordPress 的 <html lang> 由後台的網站語言設定決定，繁體中文站應該是 zh-TW。如果你當初裝的是英文版沒改語言設定，螢幕閱讀器會用英文語音去念中文，結果是完全聽不懂。
• 細字重的中文字型。中文字筆畫密，用 300 或更細的字重加上淺灰色，對比度數值可能勉強過關，但實際辨識度遠比同樣數值的英文差。W3C 在對比度的說明中也提到，筆畫特別細的字型在低對比下更難閱讀。中文本文建議至少 400 字重、16px 以上。
• 圖片形式的文字。中文排版為了字體效果，常把標語、活動資訊做成圖片。這類圖片不但螢幕閱讀器讀不到（除非 alt 寫得夠完整），放大後也會糊掉。WCAG 1.4.5 對「圖片文字」有明確限制。
• 用符號當裝飾。「◆」「※」「★」這類符號會被螢幕閱讀器逐一念出來，一整排就是一長串噪音。裝飾用途請交給 CSS。

無障礙覆蓋層外掛，為什麼身障社群普遍反對

它是什麼

無障礙覆蓋層（accessibility overlay）指的是一類第三方產品：你在網站上貼一段 JavaScript，它會在頁面右下角放一個小人圖示，點開之後有一整排開關——放大字級、提高對比、改變字距、灰階模式、停止動畫、螢幕閱讀器模式等等。部分產品還宣稱會用 AI 自動掃描並修復頁面的無障礙問題，讓網站「立即合規」。

對站主來說，這個提案聽起來完美：一行程式碼、每月幾十美元、免去整站重構。這也是為什麼過去幾年很多台灣網站也裝上了類似的工具。

反對的四個理由

國際無障礙從業者社群針對這類產品共同編寫了一份《Overlay Fact Sheet》，簽署者包含 WCAG、ARIA、HTML 規範的貢獻者與編輯，Google、Microsoft、Apple、Shopify、Target、eBay 等公司的內部無障礙專家，JAWS 與 NVDA 這兩套主要螢幕閱讀器的貢獻者，以及大量身障使用者本人（Overlay Fact Sheet 全文）。他們的論點可以整理成四點：

第一，工具列本身是多餘的。需要放大字級、需要高對比、需要語音朗讀的使用者，早就在作業系統或瀏覽器層級裝好了自己的工具，而且那套工具在所有網站上都能用。文件裡的推論很有力：如果這些功能真的是使用網站所必需，那使用者在你網站以外的每一個網站都會需要它——所以他們一定已經有了。你放的這個工具列，最好的情況下也只是重複功能。

第二，自動修復的能力有明確上限。文件列出自動修復不可靠的項目：圖片的替代文字、表單的標籤與錯誤處理與焦點控制、鍵盤操作。此外，使用 React、Angular、Vue 等元件化框架的介面，頁面狀態可能在覆蓋層無法感知的情況下改變，導致修復失效；而修復動作本身會拖慢載入，或對輔助科技使用者造成非預期的頁面變化。覆蓋層也完全無法處理 PDF、Canvas、SVG、影音檔案裡的內容。

第三，可能製造隱私問題。會自動啟用特定設定的覆蓋層，是靠偵測使用者裝置上是否正在執行輔助科技來判斷的，這等於在使用者沒有同意的情況下，揭露了「這個人有障礙」——以螢幕閱讀器使用者為例，還進一步揭露了障礙類別。文件指出，障礙與年齡、族裔、性別認同一樣屬於敏感個人資料，不應在未取得當事人知情同意的情況下蒐集。部分覆蓋層還會用 Cookie 讓設定跨網站沿用，使用者從未選擇加入、也無法退出，這會替使用覆蓋層的網站主帶來 GDPR 與 CCPA 的合規風險。

第四，也是最直接的：它不能讓你合規。文件的結論句是：

市面上沒有任何覆蓋層產品能讓一個網站完全符合任何現行的無障礙標準，因此也無法消除法律風險。

理由很單純：合規的定義是滿足標準的全部要求，而這些產品自己的文件都承認無法修復所有問題。

使用者與從業者怎麼看

WebAIM 針對無障礙從業者的調查結果，被引用在同一份文件中：67% 的受訪者認為這類工具「完全沒效」或「不太有效」；身障受訪者的評價更低，比例是 72%，只有 2.4% 認為「非常有效」。

文件中也收錄了大量身障使用者的公開發言，共同的主題是：他們得想辦法把覆蓋層擋掉才能正常使用網站。有使用者提到自己是靠在 Windows 的 hosts 檔案裡封鎖覆蓋層的網域，才終於能登入某個帳戶；也有使用者提到，覆蓋層會攔截 Tab 鍵——而 Tab 正是鍵盤導覽最標準的按鍵。

已經有主管機關開罰

這不只是社群意見。美國聯邦貿易委員會（FTC）在 2025 年 1 月對覆蓋層業者 accessiBe 發出命令，要求支付 100 萬美元，理由是該公司對其 AI 產品 accessWidget「能使任何網站符合 WCAG」的說法不實、誤導或缺乏佐證；FTC 另指控該公司付費取得第三方網站上看似中立的評論，卻未揭露利害關係。該命令禁止該公司在沒有證據支持的情況下宣稱其自動化產品能讓網站符合 WCAG 或持續維持合規。FTC 於 2025 年 4 月核准該命令為終局命令（FTC 新聞稿）。

那有沒有可以用的？

要區分兩件事。宣稱「自動讓你合規」的覆蓋層，不要用；這是上面所有論點針對的對象。單純提供使用者偏好切換的功能，例如你自己實作的深色模式、字級調整、關閉動畫開關，這些是網站本身的功能設計，只要實作正確就沒有問題——差別在於它是你自己的程式碼、可以被檢測、不會攔截鍵盤、也不會偵測使用者的輔助科技。

另外也要區分「覆蓋層」與「無障礙檢測外掛」。前者在前台改寫頁面，後者只在後台幫你找出問題、或提供修正欄位（例如批次補 alt、修正標題階層），後者是有用的工具。判斷方式：看它有沒有在前台注入一個給訪客用的工具列。有，就要警戒。

免費檢測工具怎麼用

先認清自動化工具測不到什麼

這是最重要的前提。WebAIM 在自己的報告方法論裡就寫得很直接：所有自動化工具，包括他們自己的 WAVE，都有其限制，並非所有合規失敗都能被自動偵測到；沒有偵測到錯誤，不代表頁面就是可及或合規的。

能自動測的大致是：對比度數值、缺 alt、缺 label、空連結、缺語言標記、標題跳階、地標缺漏。測不到的是：alt 寫得對不對、Tab 順序合不合理、錯誤訊息說不說得清楚、影片字幕正不正確、動畫會不會讓人不適。這些只能靠人工。所以任何工具給你的分數，只能當作「有沒有低級錯誤」的體檢，不能當作合格證。

七個免費工具與它們各自的位置

• WAVE（WebAIM）：貼網址就跑，會把錯誤直接標在頁面截圖上，適合第一次體檢與跟客戶溝通。它有瀏覽器擴充功能版，可以測還沒公開的測試站。
• WebAIM Contrast Checker：專測對比度，貼兩個色碼直接告訴你 AA 與 AAA 過不過。設計階段就該用它定色票。
• axe DevTools（Deque）：瀏覽器擴充功能，誤報率低、說明清楚，對開發者最友善。免費版足夠一般網站用。
• Lighthouse（Chrome 開發者工具內建）：會給一個無障礙分數。要注意兩件事：這個分數只反映可自動化的檢查項目，而且部分項目屬於「手動稽核」不計入分數。當作趨勢指標可以，當作合規證明不行。順帶一提它同時會給你效能報告，跟Core Web Vitals 的優化可以一起處理。
• Chrome 開發者工具的檢色器：點選任何顏色都會顯示對比值與 AA、AAA 的參考線，還能直接拖曳到通過門檻的顏色。改設計時最順手。
• NVDA：Windows 上的免費開源螢幕閱讀器。學會五個按鍵就能做基本測試：Tab 移動焦點、H 跳標題、K 跳連結、D 跳地標、Insert+F7 叫出元素清單。macOS 使用者用內建的 VoiceOver（Command+F5 開關）也可以。
• W3C WAI 的 Easy Checks：官方出的初步檢查清單，不需要任何工具，適合拿來當交付前的自查表。

如果你在做政府標案，還要加上一個：Freego，這是主管機關提供的單機版檢測工具，目前提供的是適用「網站無障礙規範(110.07)」的版本，可從無障礙網路空間服務網的下載專區取得。標章申請流程需要附上自行檢測報告，這份報告就是用它產出的。

一份三十分鐘的自檢流程

不用一次做完整稽核。下面這個順序可以在半小時內跑完，抓到的問題通常已經涵蓋八成：

1. （3 分鐘）用 WAVE 掃首頁、一篇文章頁、聯絡表單頁。先只看紅色的 Errors，黃色的 Alerts 之後再說。
2. （5 分鐘）把滑鼠拿開，只用鍵盤走完一次主要任務。記錄三件事：焦點有沒有一直看得見、有沒有卡住、順序合不合理。
3. （3 分鐘）檢查 <html lang> 是不是 zh-TW，以及頁面上是不是只有一個 h1。
4. （5 分鐘）用開發者工具列出所有 h1 到 h6，看有沒有跳號。
5. （5 分鐘）把本文顏色、次要文字顏色、連結顏色、按鈕文字顏色四組色碼丟進對比度檢查器。
6. （5 分鐘）把頁面縮放到 200%，看版面會不會爆版、有沒有出現橫向捲軸、有沒有文字被切掉。
7. （4 分鐘）關掉滑鼠，把表單填錯一次，看錯誤訊息說不說得清楚、焦點會不會自動移到出錯的欄位。

跑完之後，把問題按「影響人數 × 修復成本」排序，先修對比度與 alt（成本最低、影響最廣），再修鍵盤與焦點，最後才動表單與元件重構。

一份可以照著跑的導入順序

不要一次全做

最常見的失敗模式是：站主看完一篇無障礙文章，決定「這次要一次做到位」，開了一張三十項的清單，做到第五項就停了，然後半年不再碰。

比較能走完的做法是分成三個梯次。第一梯次只做全站性的樣式修正：對比度、焦點樣式、字級與行高、關掉自動輪播。這一梯次的特點是改一次 CSS 全站受益，通常一個下午能做完，而且改完就能在 WAVE 上看到錯誤數大幅下降。

第二梯次做模板層：補 <main> 與地標、修標題階層、加跳過連結、修表單標籤與錯誤訊息、把假按鈕換成原生元素。這一梯次要動主題檔案，建議用子主題並先備份。

第三梯次做內容層：回頭補歷史文章的 alt 與連結文字。這一梯次沒有捷徑，但可以只做流量前 20 篇——用 Search Console 排一下就知道哪些值得補。

接案時怎麼估這件事的工時

不要用「無障礙加價 20%」這種算法，客戶會覺得你在敲竹槓，你自己也估不準。比較能溝通的方式是拆成四個可計量的項目：

• 設計階段：色票對比度驗證、焦點樣式設計、元件狀態設計。這部分幾乎不增加工時，因為本來就要定色票，只是多一道檢查。
• 切版階段：語意化標籤、鍵盤可操作性、表單標籤。這部分如果一開始就做，增加的工時很少；如果上線後回頭改，成本是三到五倍。這個數字關係要在報價時就跟客戶講清楚。
• 檢測階段：自動化掃描加人工鍵盤與螢幕閱讀器測試，依頁面型態數量計算，而不是依頁數。十個相同版型的產品頁只算一種。
• 修正與複測：預留一輪。政府標案通常還要加上送件與退件修正的往返。

另外要在合約裡明確劃出責任邊界：客戶自行上傳的內容（圖片沒 alt、貼上來的表格、嵌入的第三方影片）不在你的保固範圍，但你應該交付一份簡短的內容維護指引。這一點不寫清楚，你會被無限期地叫回去改客戶自己上傳的圖。這類邊界問題跟網站常見的幾個檢查重點一樣，都是交付前就該講定的事。

寫一份無障礙聲明

這件事成本極低但很少人做。一頁說明就好，內容包含：你以什麼標準為目標（例如 WCAG 2.2 AA）、目前已知還沒做到的部分、遇到問題可以怎麼聯絡你、以及上次檢視的日期。

誠實列出「還沒做到什麼」不會扣分，反而是可信度最高的做法——沒有任何網站是百分之百的，宣稱完全合規才是風險。前面提過，WordPress 的 accessibility-ready 主題需求在 2026 年 5 月的改版中，也把「必須提供無障礙聲明」列為要求之一，這個方向是一致的。

常見問題

我的網站是純民間的部落格或小型電商，不做無障礙會不會被罰？

就台灣現行法規而言，我查不到針對純民間、非政府補助網站的普遍性強制規定或罰則。《身心障礙者權益保障法》第 52 條之 2 的義務主體是各級政府及其附屬機關（構）、學校，依其授權訂定的《各級機關機構學校網站無障礙檢測及認證標章核發辦法》適用對象也相同。但要注意三種例外情境：你承接政府標案或接受政府補助、你向歐盟消費者提供電子商務服務（歐盟無障礙法自 2025 年 6 月 28 日起適用，微型企業提供服務者有豁免）、或你的客戶是美國州與地方政府（適用美國司法部規則指定的 WCAG 2.1 AA）。另外提醒，本文整理的是公開法規資訊，不構成法律意見。

裝一個無障礙外掛就好了嗎？

要看是哪一種外掛。如果是在前台放一個給訪客用的工具列、並宣稱能自動讓網站合規的「覆蓋層」產品，答案是不行——國際無障礙從業者共同編寫的 Overlay Fact Sheet 明確指出，市面上沒有任何覆蓋層產品能讓網站完全符合任何現行無障礙標準，因此也無法消除法律風險；美國聯邦貿易委員會也在 2025 年對其中一家業者開出 100 萬美元的命令，理由是對合規能力的宣稱不實或缺乏佐證。相對地，只在後台幫你找出問題、或提供批次修正欄位的檢測類外掛是有用的工具。判斷方法很簡單：看它有沒有在前台注入一個給訪客用的工具列。

做無障礙對 SEO 有幫助嗎？

不要把它當成排名捷徑，但兩者的工作內容高度重疊。替代文字、標題階層、有意義的連結文字、正確的語言標記、語意化的 HTML 結構，這五項同時是 WCAG 的要求與 SEO 的基本功；把它們做好，搜尋引擎對你的內容理解會更完整。真正的收益其實在別的地方：鍵盤可用、對比度足夠、表單錯誤訊息清楚的網站，一般使用者的完成率也會比較高，尤其在戶外強光下用手機的情境。與其問「這對排名有沒有幫助」，不如把它當成一次結構清理，順便解決網站的其他基本功。

參考來源

• W3C，《Web Content Accessibility Guidelines (WCAG) 2.2》，W3C Recommendation，2024 年 12 月 12 日版：w3.org/TR/WCAG22
• W3C，《W3C Accessibility Guidelines (WCAG) 3.0》，Working Draft，2026 年 3 月 3 日：w3.org/TR/wcag-3.0
• W3C WAI，〈What’s New in WCAG 2.2〉：w3.org/WAI/standards-guidelines/wcag/new-in-22
• 全國法規資料庫，《身心障礙者權益保障法》所有條文：law.moj.gov.tw
• 全國法規資料庫，《各級機關機構學校網站無障礙檢測及認證標章核發辦法》：law.moj.gov.tw
• 數位發展部無障礙網路空間服務網，〈網站無障礙規範(110.07)〉：accessibility.moda.gov.tw
• WebAIM，《The WebAIM Million》2026 年報告：webaim.org/projects/million
• Overlay Fact Sheet：overlayfactsheet.com
• 美國聯邦貿易委員會新聞稿（2025 年 1 月）：ftc.gov
• ada.gov，州與地方政府網頁與行動應用程式規則說明頁：ada.gov
• EUR-Lex，Directive (EU) 2019/882：eur-lex.europa.eu
• WordPress 無障礙編碼標準：developer.wordpress.org
• Make WordPress Themes，主題審查手冊無障礙章節：make.wordpress.org