你能閉著眼滑自己的網站嗎?如果答案是否定的,代表你的團隊還沒把無障礙(a11y)放進每日流程。本篇聚焦《行動化應用軟體無障礙檢測指引》的13張檢核單,示範如何一口氣導入自動化工具,讓CI/CD幫你把關。
三大模組 × 13 張檢核單快速對照
模組 | 檢測面向 | 目標 & 快速檢核 | 常見錯誤 |
呈現組件 | AT 替代文字 / AV 時序媒體 / NT 通知 | 圖片皆有語意化 alt;影音附字幕/手語;推播可被朗讀 | `alt=””` 或放檔名;自動播放影片無停止鍵 |
互動組件 | TS 觸控操作 / FC 焦點 / FM 表單 / LK 連結 | 拖曳動作有鍵盤替代;焦點順序與外觀明顯;表單標籤/錯誤提示;連結文字具體 | 只支援觸控拖放;焦點被隱藏;placeholder 當 label |
設計方式 | DC 動態內容 / ST 結構 / AD 可調式設計 / DT 可辨識設計 / PD 可預期性 / CP 相容性 | ARIA live 區更新提示;語意化標題階層;字型可放大不破版;顏色對比 ≥ 4.5; 表單不突變;支援螢幕閱讀器 / 外接鍵盤 | AJAX 更新無提示;全站只用 <div>;16px 以下字、48px 以下點擊區 |
把 13 面向寫進 CI/CD:四步驟
一、選擇掃描引擎
– axe-core/axe DevTools:開源 + 商用完整方案,可掃描 Web 與行動 App;瀏覽器外掛一鍵掃,企業版支援閘道與報表
– Lighthouse:Google 內建的 a11y 分數,作為「門檻指標」。
– Pa11y / Playwright + @axe-core:指令列友善,適合 Headless 測試。
二、在本機 TDD
npm i -D cypress @axe-core/cypress
# cypress/support/commands.js
import ‘@axe-core/cypress’;
cy.visit(‘/’); // 載入頁面
cy.injectAxe(); // 注入掃描腳本
cy.checkA11y(null,null,(v)=>{
if(v.length) throw new Error(‘a11y Violations’);
});
建議門檻:違規數 ≤ 3 條 / 0 Blocker,超標直接 fail build。
三、併入 GitHub Actions
name: a11y-ci
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v4
– uses: actions/setup-node@v4
with: {node-version: ’20’}
– run: npm ci
– run: npx cypress run
流水線若偵測到違規,自動標紅,PR 不可併入主幹。
四、手動驗證補位
自動化平均只能抓到 ~60–80 % 問題;以下三種情境仍需人工:
- 鍵盤可用性(TS、FC)
2. 螢幕閱讀器實際朗讀(AT、NT、LK)
3. 觸覺/手勢(行動裝置 Drag & Drop, TS)
讓 a11y 融入日常 DevOps
- Story Acceptance Criteria:每張 User Story 附 a11y 檢核點(如「連結必具語意」)。
- Design Token:在 Figma 建立 color / spacing token,先天符合對比與觸控尺寸。
- Pre-commit Hook:husky + lint-staged 執行 `npm run lint:a11y`。
- 夜間 Batch 掃描:axe Monitor / Pa11y CI 針對 staging 做全站日報告。
- 分級處理:Critical 24 h 內修復;Minor 可排入 Sprint。
成本與效益試算(範例)
階段 | 若無 a11y | 導入 a11y + CI |
UI 設計修改 | 3 天 | 0.5 天 |
前端打掉重寫 | 10 天 | 1 天 |
驗收不過重工 | 5 天 | 0 天 |
總工期 | 18.0 天 | 1.5 天 |
測完才上線,不測別上線
把 13 大檢測面向寫進拉取請求(PR)的自動檢核,就像把安全帽掛在門口:所有人「經過就戴」。當 CI 持續亮綠燈,你可以安心將版本推上線;一旦亮紅燈,也能第一時間抓出責任 Commit。
—做好 a11y,使用者、老闆、SEO 都會感謝你。加油,讓無障礙成為團隊的 Default!