# Accessibility Design

> 評估與改善介面、內容與互動的無障礙品質,使產品更符合 WCAG 與包容性設計原則。當任務涉及對比度、鍵盤操作、語意化、表單可用性、螢幕閱讀器支援或 a11y 檢查時使用。

- Skill: `candy14432/accessibility-design` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add candy14432/accessibility-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/candy14432/accessibility-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- License: MIT
- Author: candy14432 (https://skillmd.com/u/candy14432)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/candy14432/accessibility-design

---


# 無障礙設計法則

## 任務定義

檢查並改善介面的可感知、可操作、可理解與穩健性,讓產品更符合 WCAG 與真實使用限制。

## 何時使用

- 任何數位產品的設計階段
- 需要符合法規要求時(如 WCAG 2.1)
- 擴大目標使用者群體時
- 改善產品整體可用性時

## 必要輸入

- 介面畫面、元件或設計稿
- 主要操作流程與互動方式
- 目前已知的無障礙問題
- 目標法規或 WCAG 等級
- 裝置與使用情境限制

## 預期輸出

- 無障礙風險清單
- 版面、內容與互動改善建議
- WCAG 對照檢查點
- 可驗證的測試清單
- 實作注意事項

## 完成條件

- 已指出主要無障礙風險與其對應的 WCAG 原則或檢查點
- 已提供設計與實作層級都可執行的改善建議
- 已涵蓋鍵盤操作、焦點狀態、語意結構與對比度等核心面向
- 已明確說明哪些問題屬高風險並需優先修正
- 已留下可供設計、前端或 QA 驗證的檢查方式

## 不適用情境

- 只想做一般視覺美化,不是 a11y 任務
- 沒有畫面、元件或流程可供檢查
- 已知問題其實是資訊架構或內容策略,不應全部歸因為無障礙

## 常見誤用

- 只檢查對比度,忽略鍵盤流程、語意與錯誤回饋
- 把無障礙當成開發收尾工作,而非設計基準
- 使用 ARIA 補救所有問題,卻沒有先修正原生語意結構
- 只列出規範條文,沒有轉成具體介面修正建議
- 沒有區分高風險問題與次要優化項目

## 觸發條件

- 使用者提到「無障礙」、「a11y」、「WCAG」、「鍵盤操作」、「對比度」、「螢幕閱讀器」
- 任務需要檢查表單、按鈕、焦點狀態或語意標記
- 任務需要把 UI 做得更包容、可及或符合法規

## 高複雜度觸發

- 任務涉及企業後台、資料密集表格、複雜表單、多步驟流程或高頻操作介面
- 使用者提到不同角色、不同裝置、不同使用能力或法規合規要求
- 問題包含鍵盤流程中斷、狀態提示不足、螢幕閱讀器難以理解、表單錯誤難以修正
- 團隊需要同時兼顧效率、合規、可操作性與大量資訊呈現

## 必要澄清

- 這個介面最關鍵的任務是什麼?哪些使用者最常使用它?
- 是否有法規、企業採購或客戶合約要求特定 WCAG 等級?
- 使用者會使用哪些輔助技術?例如螢幕閱讀器、鍵盤操作、放大模式
- 哪些元件最複雜?例如資料表格、日期選擇器、拖曳、圖表或多步驟表單
- 目前已知的無障礙痛點是什麼?是看不見、聽不到、點不到還是難以理解?
- 這次要先做設計檢查、實作建議還是驗證測試清單?

## 可搭配技能

- `design-system`: 把無障礙規範沉澱到元件與 token 中
- `usability-testing`: 邀請不同能力的使用者驗證改善方案
- `wireframing`: 在早期調整版面與流程避免後期返工
- `prototyping`: 模擬焦點流、錯誤回饋與狀態變化

## 執行步驟

1. 定義標準: 先確認目標等級,預設以 WCAG 2.1 AA 為基準。
2. 找高風險問題: 優先檢查對比度、鍵盤操作、焦點、語意、表單、錯誤回饋。
3. 產出修正建議: 每個問題都要對應具體介面修正與驗證方式。
4. 做手動驗證: 只用鍵盤操作,檢查焦點順序、螢幕閱讀器可讀性與縮放表現。
5. 建立長期規則: 把高頻 a11y 規則沉澱到元件與設計規範中。

## 執行檢查

- [ ] 已定義目標等級與適用範圍
- [ ] 已檢查對比度、焦點、鍵盤與語意結構
- [ ] 已補齊表單標籤、錯誤訊息與狀態回饋
- [ ] 已規劃手動測試方式
- [ ] 已標記高風險問題優先修正

## 精簡範例輸出

```markdown
# A11y 檢查結果

- 目標標準: WCAG 2.1 AA
- 高風險問題: 焦點不明顯、錯誤訊息未被朗讀、表單缺 label

修正建議:
- 所有按鈕加入可見 focus 樣式
- 錯誤訊息與欄位透過 aria-describedby 關聯
- 圖示按鈕補 aria-label
```

## 範例資料庫

本技能提供完整的無障礙設計範例庫，請參考 `examples.yaml`：

- **WCAG 檢查清單**：可感知、可操作、可理解、穩健性四大原則的詳細檢查項目
- **ARIA 模式**：按鈕、對話框、選單、標籤頁等常見元件的 ARIA 使用範例
- **螢幕閱讀器測試**：NVDA、JAWS、VoiceOver 等工具使用指南
- **常見問題**：低對比度、缺少 alt 文字等問題的解決方案
- **測試工具**：自動化和手動測試工具清單

使用方式：使用檢查清單逐項檢查，參考 ARIA 模式實作無障礙元件。

## 資料使用規則

- 產出內容前，**先閱讀** `TEMPLATE.md`，確認欄位結構、最小必要欄位、品質標準與驗證方式。
- 接著再閱讀 `examples.yaml`，從既有檢查清單、ARIA 模式、測試方式與問題解法中選取最適合的內容。
- 若要新增資料，優先沿用 `TEMPLATE.md` 的格式與命名規則，避免建立重複或標準不一致的檢查項。
- 最終輸出必須優先對齊 `TEMPLATE.md` 的格式要求，其次再引用 `examples.yaml` 的內容細節。