フレームワーク活用ガイド
押さえておきたい用語
- WCAG: Web Content Accessibility Guidelinesの略。ウェブコンテンツのアクセシビリティに関する国際規格
- POUR原則: Perceivable（知覚可能）、Operable（操作可能）、Understandable（理解可能）、Robust（堅牢）の4原則
- 適合レベル: A（最低限）、AA（標準）、AAA（最高）の3段階。多くの法規制はAAレベルを要求
- 支援技術: スクリーンリーダー、音声認識、スイッチデバイスなど障害のあるユーザーが使う技術
1
4原則の理解
POUR各原則の要件と適合レベルを把握 → 自動テスト
こんな悩みに効く#
- 「アクセシビリティ対応が必要だが何から始めればいいか分からない」
- 「法的要件（障害者差別解消法等）への準拠状況を確認したい」
- 「視覚・聴覚・運動に障害のあるユーザーにも使えるプロダクトにしたい」
使い方#
自動テストで機械的に検出する
axe DevTools、Lighthouse、WAVEなどの自動テストツールでサイト全体をスキャンする。コントラスト不足、alt属性の欠落、ARIA属性の誤りなど、機械的に検出できる問題を先に洗い出す。全問題の30〜40%はこの段階で発見できる。
キーボードとスクリーンリーダーで手動検証する
Tabキーだけでサイト全体を操作し、フォーカス順序・フォーカス表示・操作可能性を確認する。VoiceOver（Mac）やNVDA（Windows）でスクリーンリーダー体験を検証する。自動テストでは見つからない問題の多くがここで発見される。
影響度で修正の優先順位を決める
すべての問題を一度に修正するのは現実的でない。「操作不能」（キーボードでアクセスできないフォーム等）→「知覚不能」（代替テキストなしの画像等）→「理解困難」（エラーメッセージの改善等）の順で優先する。
CI/CDに組み込んで継続的に監視する
修正後のレグレッション（後退）を防ぐために、axe-coreやpa11yをCI/CDパイプラインに組み込む。新機能のプルリクエストでアクセシビリティ違反が検出されたらビルドを失敗させる設定が効果的だ。
具体例#
ECサイト — WCAG AA準拠プロジェクト
状況: 障害者差別解消法の合理的配慮義務化（2024年施行）を受け、ECサイトのアクセシビリティ対応が急務に。社内に知見がなく、どこから着手すべきか分からなかった。
適用プロセス:
- 自動テストで128件の問題を検出。最多はコントラスト不足（47件）とalt属性欠落（32件）
- キーボードテストで商品フィルターがTab操作できないことが判明（操作不能の致命的問題）
- 修正優先順位：操作不能の修正（2週間）→コントラスト修正（1週間）→alt属性追加（1週間）→エラーメッセージ改善（1週間）
成果: 5週間でWCAG AA適合率が34%→92%に向上。副次的にSEOスコアも改善し、オーガニック流入が12%増加した。
SaaS — スクリーンリーダー対応の強化
状況: 視覚障害のあるユーザー企業から「ダッシュボードがスクリーンリーダーで使えない」とフィードバック。自治体向けSaaSのため、アクセシビリティ未対応は入札要件を満たせないリスクがあった。
適用プロセス:
- VoiceOverでダッシュボードを操作し、グラフ・テーブル・モーダルの3箇所が完全に読み上げ不能と判明
- グラフにaria-label＋データテーブルの代替表示を追加。テーブルにscope属性と列ヘッダーの紐づけを実装
- モーダルにフォーカストラップとaria-modal属性を追加し、Escキーで閉じる操作を実装
成果: スクリーンリーダーでの主要タスク完了率が0%→85%に改善。3件の自治体入札で要件適合が認められ、うち2件を受注した。
メディアサイト — 動画コンテンツのアクセシビリティ
状況: ニュースメディアの動画コンテンツが月100本以上あるが、字幕なし。聴覚障害ユーザーから改善要望が寄せられ、さらに自動字幕のSEO効果も期待されていた。
適用プロセス:
- POUR原則の「P（知覚可能）」に基づき、動画コンテンツの字幕対応を最優先に
- AI文字起こしツールで自動字幕を生成し、編集者が校正するワークフローを構築。1本あたりの字幕作成時間を30分に短縮
- 重要度の高い動画にはテキストトランスクリプト（全文書き起こし）も追加
成果: 字幕付き動画の視聴完了率が字幕なしと比較して23%高い結果に。動画ページのSEO流入が35%増加し、ビジネス面でもアクセシビリティ投資の効果が証明された。
うまくいかないパターン#
| パターン | 問題点 | 対処法 |
|---|---|---|
| 自動テストだけで完了とする | 自動検出できるのは全問題の30〜40%にすぎない | 手動テスト（キーボード・スクリーンリーダー）を必ず併用する |
| リリース直前に一括対応する | 修正コストが膨大になり品質も低下する | 開発プロセスの初期段階からアクセシビリティを組み込む |
| AAAレベルを最初から目指す | 要件が厳しすぎて着手できなくなる | まずAAレベルの達成に集中する |
| デザイナーだけの責任にする | HTMLの構造やARIA属性はエンジニアの実装が必要 | デザイナーとエンジニアの共同責任として取り組む |
まとめ#
WCAGの4原則（POUR）は「誰もが使える」ウェブを実現するための設計指針だ。知覚可能（見える・聞こえる）、操作可能（使える）、理解可能（分かる）、堅牢（壊れない）の4つをバランスよく満たすことで、障害の有無にかかわらず情報にアクセスできる。自動テストと手動テストを組み合わせ、CI/CDに組み込んで継続監視する仕組みが、アクセシビリティ品質の持続に不可欠だ。