AI Skills
accessibility

accessibility

熱門

使用 WCAG 2.2 Level AA 標準設計、實作與稽核包容性數位產品。運用此技能為網頁產生語意化 ARIA，並為網頁及原生平台（iOS/Android）產生無障礙屬性。

23萬星標
3.5萬分支
更新於 2026/7/21
獲取技能源代碼

相關技能

frontend-skill8.4萬frontend-ui-engineering7.7萬oversized-cursor3.6萬
SKILL.md
readonlyread-only
name
accessibility
description

Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA

無障礙設計（WCAG 2.2）

此技能確保數位介面對所有使用者（包括使用螢幕報讀軟體、切換控制或鍵盤導航的使用者）是可感知、可操作、可理解且穩健的（POUR）。重點在於 WCAG 2.2 成功準則的技術實作。

使用時機

  • 定義網頁、iOS 或 Android 的 UI 元件規格。
  • 稽核現有程式碼的無障礙障礙或合規差距。
  • 實作新的 WCAG 2.2 標準，例如目標大小（最小）與焦點外觀。
  • 將高階設計需求對應到技術屬性（ARIA 角色、屬性、提示）。

核心概念

  • POUR 原則：WCAG 的基礎（可感知、可操作、可理解、穩健）。
  • 語意對應：使用原生元素而非通用容器，以提供內建的無障礙支援。
  • 無障礙樹：輔助技術實際「讀取」的 UI 表示。
  • 焦點管理：控制鍵盤/螢幕報讀軟體游標的順序與可見性。
  • 標籤與提示：透過 aria-label、accessibilityLabel 和 contentDescription 提供上下文。

運作方式

步驟 1：識別元件角色

判斷功能目的（例如：這是按鈕、連結還是分頁？）。在自訂角色之前，優先使用最語意的原生元素。

步驟 2：定義可感知屬性

  • 確保文字對比度達到 4.5:1（一般文字）或 3:1（大型文字/UI）。
  • 為非文字內容（圖片、圖示）加入文字替代。
  • 實作回應式重排（縮放至 400% 而不損失功能）。

步驟 3：實作可操作控制項

  • 確保最小 24x24 CSS 像素 的目標大小（WCAG 2.2 SC 2.5.8）。
  • 確認所有互動元素可透過鍵盤到達，並有可見的焦點指示器（SC 2.4.11）。
  • 為拖曳動作提供單一指標替代方案。

步驟 4：確保可理解的邏輯

  • 使用一致的導航模式。
  • 提供描述性的錯誤訊息與修正建議（SC 3.3.3）。
  • 實作「避免重複輸入」（SC 3.3.7），防止要求相同資料兩次。

步驟 5：驗證穩健的相容性

  • 使用正確的 Name, Role, Value 模式。
  • 為動態狀態更新實作 aria-live 或即時區域。

無障礙架構圖

flowchart TD
  UI["UI 元件"] --> Platform{平台?}
  Platform -->|網頁| ARIA["WAI-ARIA + HTML5"]
  Platform -->|iOS| SwiftUI["無障礙屬性 + 標籤"]
  Platform -->|Android| Compose["語意 + 內容描述"]

  ARIA --> AT["輔助技術（螢幕報讀軟體、切換控制）"]
  SwiftUI --> AT
  Compose --> AT

跨平台對應表

功能 網頁 (HTML/ARIA) iOS (SwiftUI) Android (Compose)
主要標籤 aria-label / <label> .accessibilityLabel() contentDescription
次要提示 aria-describedby .accessibilityHint() Modifier.semantics { stateDescription = ... }
動作角色 role="button" .accessibilityAddTraits(.isButton) Modifier.semantics { role = Role.Button }
即時更新 aria-live="polite" .accessibilityLiveRegion(.polite) Modifier.semantics { liveRegion = LiveRegionMode.Polite }

範例

網頁：無障礙搜尋

<form role="search">
  <label for="search-input" class="sr-only">搜尋產品</label>
  <input type="search" id="search-input" placeholder="搜尋..." />
  <button type="submit" aria-label="提交搜尋">
    <svg aria-hidden="true">...</svg>
  </button>
</form>

iOS：無障礙動作按鈕

Button(action: deleteItem) {
    Image(systemName: "trash")
}
.accessibilityLabel("刪除項目")
.accessibilityHint("永久從清單中移除此項目")
.accessibilityAddTraits(.isButton)

Android：無障礙切換開關

Switch(
    checked = isEnabled,
    onCheckedChange = { onToggle() },
    modifier = Modifier.semantics {
        contentDescription = "啟用通知"
    }
)

應避免的反模式

  • Div 按鈕：使用 <div> 或 <span> 處理點擊事件，卻未加入角色與鍵盤支援。
  • 僅用顏色表達意義：僅透過顏色變化（例如將邊框變紅）來表示錯誤或狀態。
  • 未限制焦點的模態框：模態框未限制焦點，導致鍵盤使用者在模態框開啟時仍可導航背景內容。焦點必須被限制，且可透過 Escape 鍵或明確的關閉按鈕離開（WCAG SC 2.1.2）。
  • 冗餘替代文字：在替代文字中使用「圖片...」或「照片...」（螢幕報讀軟體已會宣告「圖片」角色）。

最佳實務檢查清單

  • [ ] 互動元素符合 24x24px（網頁）或 44x44pt（原生）的目標大小。
  • [ ] 焦點指示器清晰可見且高對比。
  • [ ] 模態框開啟時限制焦點，關閉時乾淨釋放（Escape 鍵或關閉按鈕）。
  • [ ] 下拉選單與選單在關閉時將焦點回到觸發元素。
  • [ ] 表單提供文字形式的錯誤建議。
  • [ ] 所有僅圖示的按鈕都有描述性文字標籤。
  • [ ] 文字縮放時內容能正確重排。

參考資料

相關技能

  • frontend-patterns
  • design-system
  • liquid-glass-design
  • swiftui-patterns