TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
axe-core 無障礙掃描教學：一行指令檢查 AI 生成的網頁
axe-core 是 Deque 維護的開源無障礙檢查引擎，一行指令就能掃出 AI 生成網頁的違規清單。實際以 4.14.0 版掃描兩個目標：問題示範頁抓到 8 條違規、本站首頁 1 條違規外加 12 處 incomplete。官方自述平均涵蓋 57% 的 WCAG 問題，違規歸零之後，鍵盤與理解層仍需人工驗收。
用 AI 摘要這篇文章：
讓 AI 幫你生成網頁之後，「有沒有做無障礙」常常只剩一句形容詞：你叫它注意無障礙，它回你已盡力處理，然後雙方都沒有東西可以核對。axe-core 補的就是這一塊。它是 Deque 維護的開源無障礙檢查引擎，在瀏覽器裡對渲染後的頁面跑一組有明確判準的規則，把結果變成帶節點、帶嚴重度、帶修正建議的清單。一行指令就能跑，不用裝任何商業軟體。
我實際用 2026 年 10 月發布的 4.14.0 版跑了兩個目標。一張自己寫的、刻意放了十幾個問題的訂位示範頁，掃出 8 條違規規則、18 處違規節點；拿本站首頁再跑一次，只列 1 條確定違規（對比不足，2 處），但另有 12 處落在 axe 不敢替你判斷的分類裡。這個「不敢判斷」正是使用這類工具最需要理解的東西：官方 README 明言 axe 平均只能自動找出 57% 的 WCAG 問題，無法確定的元素會以 incomplete 回報，剩下的要人工檢視。違規歸零是可核對的驗收點，但它是起點，不是無障礙的證明。
需要無障礙標章的網站，眼前還有一個具體時程：數位發展部公告，2026 年 11 月 30 日起正式實施修正版「網站無障礙規範（115.11）」認證標章檢測，同日起不再受理舊版 110.7 的標章申請。政府網站與需要標章的單位都在對這個時程整備，先讓自己的頁面過得去一套規則檢查，是任何檢測流程前的自檢基本功。下面從把掃描跑起來開始，一路到讀懂輸出、接進流程，以及官方 MCP 整合的付費牆長在哪裡。
一行指令先跑起來，三分鐘內看到第一份報告
前置只有兩樣：裝好 Node.js（npx 隨附），以及機器上的 Chrome，掃描會以無頭模式驅動它。開終端機，貼這行：
npx -y @axe-core/[email protected] https://techmoon.xyz --save result.json --exit
跑完終端機會逐條印出違規，格式是違規規則的 ID、發生次數，以及每個出問題元素的選擇器，每條都附一條連到 Deque University 該規則文件頁的網址，點進去能看到定義、為什麼嚴重、怎麼修。我這次實跑收到的輸出是「18 Accessibility issues detected. Testing complete of 1 pages」，外加一份 result.json。
三個常用參數先記起來。--save 把完整結果存成 JSON，後續要回餵給 AI 修的就是這份檔案；--exit 讓掃描在有任何規則未通過時以失敗碼離開，這是把掃描變成自動化閘門的開關；--timeout 給載入慢或頁面很大的目標多一點時間，官方文件自己拿新聞網站當例子。要縮小範圍可以用 --tags wcag2a 這類寫法只跑特定標籤的規則。
兩個小細節順手記下。掃描是在你自己的終端機與本機 Chrome 裡完成的，回報對象就是你自己，沒有雲端儀表板；--tags 與 --rules 的差別是前者整組套用（例如所有 wcag2a 規則）、後者逐條點名，過渡期縮範圍時兩者都好用。預設瀏覽器不合用就加 --browser 指定。
驗證自己有沒有做對很直接：打開存下來的 JSON，能看到 violations、passes、incomplete、inapplicable 四個陣列，就代表整條鏈跑通了。這四個分類怎麼讀，是下一節的重點。
四種分類各代表什麼，incomplete 不是沒事
violations 是引擎有把握判定違規的規則，每一條附 impact 嚴重度，由輕到重是 minor、moderate、serious、critical。passes 是通過的規則。inapplicable 是頁面上沒有對應元素、規則根本不用跑，例如頁面完全沒有影片時，字幕相關規則就整組不適用。最容易被忽略的是 incomplete：引擎無法確定、需要人看的那一批。
拿本站首頁的實跑結果當例子最清楚。violations 只有一條 color-contrast，2 處，都是文章分類標籤的連結文字對比不足，impact 標 serious。但 incomplete 裡躺著 color-contrast 11 處、aria-prohibited-attr 1 處。對比這種規則要算出文字與背景的實際顏色，遇到漸層、半透明疊層或圖片背景，引擎算不準時就誠實地說不確定。所以「只列 1 條違規」的正確讀法是：1 條確定違規，加 12 處機器不敢判斷、等你裁決。
官方對這條邊界寫得一點都不含糊。README 原文的說法是，axe-core 平均可自動找出 57% 的 WCAG 問題，無法確定的元素會以 incomplete 回傳並需要人工檢視；同一份宣言也標榜回報結果零誤報，程式臭蟲除外。兩句合起來就是這個工具的誠實使用說明：它報出來的違規可信度高，但它涵蓋不了的地方比它涵蓋的地方更需要你花力氣。
規則的範圍也值得先看一眼。4.14.0 的規則文件把規則分組：對應 WCAG 2.0 的 A 與 AA 有 60 條、WCAG 2.1 有 3 條、WCAG 2.2 有 1 條，另外有 27 條最佳實踐規則；AAA 等級 3 條、實驗中 6 條、已棄用 5 條各自獨立分節。也就是說日常掃描的主戰場是 WCAG 的 A 與 AA 準則，這與多數法規要求的等級一致。
拿一張問題頁實測：八條抓到，一條漏網
為了看清楚邊界，我寫了一張刻意放滿問題的小訂位頁：圖片沒有替代文字、按鈕沒有文字、輸入欄位沒有標籤、html 沒有 lang、低對比的文字連結、多個 tabindex 大於零的元素，以及完全沒有 landmark 結構的版面。axe-core 4.14.0 掃描結果如下，18 處違規、23 條規則通過：
| 違規規則 | 嚴重度 | 處數 | 它抓到的問題 |
|---|---|---|---|
| image-alt | critical | 1 | 圖片缺少替代文字 |
| button-name | critical | 1 | 按鈕沒有可辨識文字 |
| label | critical | 1 | 表單欄位沒有標籤 |
| html-has-lang | serious | 1 | html 元素缺 lang 屬性 |
| color-contrast | serious | 1 | 文字對比不足 |
| tabindex | serious | 3 | tabindex 大於零，打亂鍵盤聚焦順序 |
| landmark-one-main | moderate | 1 | 缺少主要內容區 |
| region | moderate | 9 | 內容沒有被 landmark 包住 |
但這張頁面上還有一個更根本的問題，清單裡任何一條都沒有以「鍵盤用不了」的理由點名它：送出訂位是一個掛了 onclick 的 div，還掛了 role 告訴輔助技術把它當裝飾。滑鼠點得到，鍵盤完全走不到，對只使用鍵盤的人而言這個流程在第一步就斷了。它最後只出現在 region 那條的附帶節點裡，原因是「沒被包進結構區」，跟鍵盤無關。
這就是 57% 這個數字在實務上的長相。能不能用鍵盤走完整個流程、焦點順序合不合理、螢幕閱讀器把重點讀出來了沒、文字本身好不好懂，這幾件事自動規則天生給不了答案。所以比較務實的驗收組合是：掃描清單歸零，加上三件人工檢查，只使用鍵盤走一遍主流程、用一個螢幕閱讀器聽一遍關鍵互動、自己讀一遍主要文案。掃描把機器能判的先清乾淨，人力只花在機器判不了的地方。
接進 AI 產頁流程：清單回餵、重掃、用結束碼當閘門
知道怎麼讀報告之後，把它放進 AI 生成網頁的工作流就順了。整個迴圈是：AI 產出頁面，axe 掃一次，把 JSON 裡 violations 的規則 ID、出問題的節點選擇器與 failureSummary 整段貼回給 AI，要求它只修這些節點，修完重掃，直到 --exit 回傳成功碼。跟「請注意無障礙」比起來，差別在於每次修改都有可核對的前後狀態，AI 也不能用一句已處理交差。這個道理與把網頁效果的官方條件寫進需求是同一件事：交辦的內容越能對照規格與判準，產出來的東西越驗收得回來。
要讓這個閘門自動化，把 @axe-core/playwright 掛進你既有的瀏覽器測試即可，套件版本與核心同為 4.14.0、同樣是 MPL-2.0 授權，測試碼裡呼叫 AxeBuilder 對指定頁面分析，違規就讓測試失敗。從此每次建置都會擋，不用靠人記得手動跑，與捲動動畫先定時間軸再驗收的做法一樣，都是把驗收條件寫成機器可判的東西。回頭核對修改成效也有個省力法：重掃前後各存一份 JSON，比對同一規則的節點數變化，AI 說修好了但 color-contrast 從 2 處變 3 處這種事，一眼就現形。
三個常見症狀與處理方式先備著。症狀一：掃描歸零，但鍵盤實測卡住。這不是掃描器壞了，而是上一節說的天險，回到三件人工檢查，機器無解。症狀二：單頁應用程式掃不到動態內容。掃的是呼叫當下的 DOM，內容還沒渲染就掃了個寂寞，用 Playwright 在互動後、渲染完成時才觸發分析，或把 CLI 的 --timeout 拉長等頁面就緒。症狀三：CI 被既存違規擋到沒辦法建置。過渡期先用 --tags wcag2a,wcag2aa 縮小規則範圍，或暫時拿掉 --exit 讓掃描只出報告不擋路，等清償完再掛回來。
rollback 也簡單：整個流程不動你的原始碼，掃描只是讀取頁面。不想要閘門就拿掉 --exit，不想要報告就移除指令，網站本身一個位元組都不用改。
官方 MCP 整合在哪，免費與付費的分界線
看到 AI 代理與 MCP 的讀者可能會問：能不能讓 AI 直接呼叫掃描、自動修？官方確實出了 Axe MCP Server，提供 analyze 掃描與 remediate 產生程式碼級修復建議兩個工具，倉庫 2026 年 11 月中還有更新。但它的授權標章寫的是 Proprietary，需求清單寫得明白：Docker、Axe DevTools for Web 的付費訂閱，以及一組 API key。官方 README 甚至直接加粗提醒這需要付費訂閱。
免費路線與付費路線的分界因此很清楚。規則引擎本體 axe-core、CLI、Playwright 套件全部開源免費，你完全可以自己把 JSON 違規清單貼給任何 AI 編輯器，組出回餵修改的迴圈，效果就是前面幾節的內容。要的是官方包好的 IDE 內掃描加修復建議，那是在買工作流整合，不是在買檢查能力。另外 GitHub 上也找得到社群自製的無障礙掃描 MCP 伺服器，非官方出品、授權與維護狀態各異，採用前自己查一遍。我沒有測試付費產品，兩者的修復效果無從比較，這一點不替任何一方背書。
對時 115.11：標章檢測 2026 年 11 月 30 日上路
數位發展部無障礙網路空間服務網的公告值得整段看清楚：規範已於民國 115 年 5 月 29 日（2026-05-29）以數位政府字第 11540006711 號令修正發布，自 115 年 11 月 30 日（2026-11-30）起正式實施修正版「網站無障礙規範（115.11）」認證標章檢測，同日起不再受理「網站無障礙規範（110.7）」的標章申請；在此之前取得的標章，效期仍然是 3 年。
對正在用 AI 大量產出頁面的團隊，這個時程的意義是把自檢提前。axe 的規則標籤直接對應 WCAG 的準則編號（wcag2a、wcag2aa 等），掃描結果等於先幫你把機器可判的 WCAG 項目清點一輪；但標章是服務網的檢測與認證流程，服務網自己也提供單機版檢測工具 Freego，兩者不是同一件事。掃描零違規不等於取得標章，也不等於通過檢測，它只是讓你帶著一張比較乾淨的底稿走進正式流程。
把規範沿革拉開看，這次換版其實是同一條路的第三次對表：我國 2002 年訂定「無障礙網頁開發規範」，2017 年實施對應 WCAG 2.0 的「網站無障礙規範 2.0」，現行的 110.7 版納入 WCAG 2.1 的行動裝置條文。服務網的說明頁也把這段沿革寫得很清楚，查任何舊資料時先對一下版本，才不會拿前朝的檢測碼套今天的頁面。
這套工具做不到的事，與我會怎麼用
最後把限制攤開。57% 是官方給的平均值，換到你的頁面上未必是同一個數字；動態渲染、登入後才出現的畫面、iframe 與需要互動才展開的內容，都會讓實際涵蓋範圍縮水。規則集合會隨版本變動，4.14.0 就把 label-content-name-mismatch 這條規則改為預設啟用，升級版本後違規數字變了先別驚訝，那是規則變嚴或效能改善（官方量測多數頁面加速 20% 到 40%）的結果，所以建議鎖定版本跑，升級時重新讀一遍報告。
我的用法建議分三層。自用網站與 side project，免費核心加三件人工檢查就綽綽有餘，一分錢不用花。團隊開發，把 Playwright 掃進 CI 當閘門，違規歸零才能合併，讓問題進不了主幹。需要官方 IDE 內整合與修復建議，再去評估訂閱，並把採購理由寫在工作流而非檢查力上。至於鍵盤、聚焦、理解難度這三件事，無論花不花錢，永遠是你自己的眼睛與雙手的工作。
