アクセシビリティ (WCAG 2.2) は何をしますか？
このスキルは、スクリーンリーダー、スイッチコントロール、キーボードナビゲーションを使用するユーザーを含むすべてのユーザーにとって、デジタルインターフェースが知覚可能、操作可能、理解可能、堅牢 (POUR) であることを保証します。WCAG 2.2 達成基準の技術的な実装に焦点を当てています。
使用時
- Web、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 Component"] --> Platform{Platform?}
Platform -->|Web| ARIA["WAI-ARIA + HTML5"]
Platform -->|iOS| SwiftUI["Accessibility Traits + Labels"]
Platform -->|Android| Compose["Semantics + ContentDesc"]
ARIA --> AT["Assistive Technology (Screen Readers, Switches)"]
SwiftUI --> AT
Compose --> AT
クロスプラットフォームマッピング
| 機能 | Web (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 } |
例
Web: アクセシブルな検索
<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（Web）または 44x44pt（ネイティブ）のターゲットサイズを満たしている。
- フォーカスインジケータが明確に可視であり、高いコントラストである。
- モーダルは開いている間 フォーカスを閉じ込め、閉じる際に（
Escapeキーまたは閉じるボタンで）クリーンに解放する。 - ドロップダウンとメニューは閉じる際にトリガー要素にフォーカスを戻す。
- フォームはテキストベースのエラー提案を提供する。
- アイコンのみのボタンにはすべて、説明的なテキストラベルがある。
- テキストを拡大したときにコンテンツが適切にリフローする。
参考文献
- WCAG 2.2 ガイドライン
- WAI-ARIA オーサリングプラクティス
- iOS アクセシビリティプログラミングガイド
- iOS ヒューマンインターフェースガイドライン - アクセシビリティ
- Android アクセシビリティデベロッパーガイド
関連スキル
frontend-patternsdesign-systemliquid-glass-designswiftui-patterns