wcag-audit-patterns

WCAG 監査パターン

WCAG 2.2 ガイドラインに照らして Web コンテンツを監査し、実行可能な修正戦略を提示するための包括的なガイドです。

このスキルを使用する場面

• アクセシビリティ監査を実施する
• WCAG 違反を修正する
• アクセシブルなコンポーネントを実装する
• アクセシビリティ訴訟に備える
• ADA/Section 508 の要件を満たす
• VPAT 準拠を達成する

中核となる概念

1. WCAG 準拠レベル

レベル	説明	必要な場面
A	最低限のアクセシビリティ	法的な基準ライン
AA	標準的な準拠	ほとんどの規制
AAA	強化されたアクセシビリティ	特別なニーズ

2. POUR 原則

Perceivable:  Can users perceive the content?
Operable:     Can users operate the interface?
Understandable: Can users understand the content?
Robust:       Does it work with assistive tech?

3. 影響度別の一般的な違反

Critical (Blockers):
├── Missing alt text for functional images
├── No keyboard access to interactive elements
├── Missing form labels
└── Auto-playing media without controls

Serious:
├── Insufficient color contrast
├── Missing skip links
├── Inaccessible custom widgets
└── Missing page titles

Moderate:
├── Missing language attribute
├── Unclear link text
├── Missing landmarks
└── Improper heading hierarchy

詳細なパターンと実例

詳細なパターンのドキュメントは references/details.md にあります。上記のナビゲーション階層では不十分な場合は、そのファイルを参照してください。

ベストプラクティス

やるべきこと

• 早い段階から始める - 設計フェーズからアクセシビリティを考慮する
• 実際のユーザーでテストする - 障害のあるユーザーが最良のフィードバックを提供する
• 自動化できることは自動化する - 問題の 30～50% は検出可能
• セマンティック HTML を使用する - ARIA の必要性を減らす
• パターンを文書化する - アクセシブルなコンポーネントライブラリを構築する

避けるべきこと

• 自動テストだけに頼らない - 手動テストが必要
• ARIA を最初の解決策にしない - まずネイティブ HTML
• フォーカスアウトラインを隠さない - キーボードユーザーには必要
• ズームを無効にしない - ユーザーはサイズ変更する必要がある
• 色だけに頼らない - 複数の指標が必要