WCAG 2.1 AA準拠の進め方：基準の理解から実装、テスト、継続運用まで

WCAG 2.1とレベルAAの意味

WCAGは、Web Content Accessibility Guidelinesの略称です。
WCAG 2.1のW3C勧告は、ウェブコンテンツを知覚可能、操作可能、理解可能、堅牢にするための達成基準を示しています。

適合レベルにはA、AA、AAAがあります。
レベルAAに適合するには、レベルAAの達成基準だけでなく、レベルAとレベルAAの達成基準をすべて満たす必要があります。

したがって、次に挙げる項目は「AA準拠に必要な基準の例」であり、完全なチェックリストではありません。
適合を表明する場合は、W3Cの適合性に関する解説と達成基準の原文を参照し、ページ全体と一連の操作を対象に評価します。

代表的な達成基準を実装と確認方法に結び付ける

キーボード操作とブロックスキップはレベルAですが、レベルAA適合にはレベルAも含まれるため確認が必要です。
各項目を独立した改善として扱わず、ページや申込手続き全体で利用できるかを確かめます。

実装例で押さえる三つのポイント

配色は色コードではなく組み合わせで判定する

コントラスト比は、前景色と背景色の明るさの差を数値にしたものです。
同じ文字色でも背景が変われば結果が変わるため、CSSの色コードだけを見て合否を決めることはできません。

:root {
  --page-background: #ffffff;
  --body-text: #333333;
  --link-text: #005ea8;
}

body {
  background: var(--page-background);
  color: var(--body-text);
}

a {
  color: var(--link-text);
  text-decoration: underline;
}

この例の色は出発点にすぎません。
実際の背景、文字サイズ、太さ、状態ごとに測定し、リンクは色だけに頼らず下線などでも区別します。
詳しい確認手順は、関連記事のコントラスト比の意味と確認方法で確認できます。

フォーカス表示は操作位置を伝える

フォーカスは、次のキー操作を受け取る要素を示す状態です。
表示を消すと、キーボード利用者は現在位置を見失います。

:focus-visible {
  outline: 3px solid #000000;
  outline-offset: 3px;
  box-shadow: 0 0 0 2px #ffffff;
}

二重の輪郭は一例であり、すべての背景で見えることを自動的に保証するものではありません。
実画面でフォーカス順序と見え方を確認し、モーダルやメニューを閉じた後に操作位置が適切な場所へ戻るかも試します。
実装と確認の流れは、キーボード操作の実装方法と確認ポイントも参考になります。

フォームはエラーの場所、理由、直し方を結ぶ

次のコードは、送信後にメールアドレスの形式エラーが判明した状態の例です。
ラベルを入力欄に結び付け、aria-invalidで無効な状態を示し、aria-describedbyで説明とエラーメッセージを参照します。

<label for="email">メールアドレス（必須）</label>
<p id="email-help">例：name@example.com</p>
<input
  id="email"
  name="email"
  type="email"
  required
  aria-invalid="true"
  aria-describedby="email-help email-error"
>
<p id="email-error">「@」を含むメールアドレスを入力してください。</p>

初期表示ではエラーを出さず、検証後に該当する入力欄へ状態と説明を追加します。
動的にエラーを表示する場合は、読み上げの通知方法も操作の流れに合わせて確認します。
フォーム全体の設計は、アクセシブルなフォームのラベル、入力支援、エラー通知で詳しく解説しています。

自動検査と手動検査を使い分ける

自動検査は、機械が判定できる規則違反を広く見つけるのに向いています。
ただし、自動検査の合格率だけでは、すべての達成基準への適合や実際の使いやすさを判断できません。

1. 自動検査を行う：axeやLighthouseなどで、機械的に検出できる問題の候補を集めます。
2. キーボードで操作する：TabキーとShift＋Tabキーで移動し、順序、フォーカス表示、実行、閉じる操作、キーボードトラップの有無を確認します。
3. 画面読み上げを確認する：NVDAやVoiceOverなどで、見出し、ラベル、読み上げ順、エラー通知が意図どおり伝わるかを試します。
4. 表示条件を変える：文字の拡大や狭い画面幅でも、内容や操作が失われないかを確認します。
5. 利用者による評価を加える：可能であれば障害のある利用者にも参加してもらい、達成基準の検査だけでは見えにくい利用上の問題を把握します。

検出結果は件数だけで管理せず、該当する達成基準、影響するページ、再現手順、修正後の確認結果を残します。
これにより、同じ問題の再発を追跡しやすくなります。

AA準拠に向けた実務の進め方

1. 対象を決める：URL一覧だけでなく、共通テンプレート、ログイン、検索、入力、確認、完了までの操作を洗い出します。
2. 基準と現状を対応付ける：問題を達成基準に結び付け、利用を妨げるものから優先順位を付けます。
3. 共通部品から直す：ヘッダー、ナビゲーション、ボタン、入力欄など、複数ページで使う部品を先に改善します。
4. 異なる方法で再検査する：自動検査、キーボード操作、画面読み上げ、表示変更を組み合わせ、修正による別の不具合も確認します。
5. 判断と結果を記録する：対象範囲、参照したWCAGの版、達成レベル、未解決事項、検査日を残します。
6. 変更のたびに確認する：新機能、デザイン変更、コンテンツ更新を公開するとき、該当する検査を開発と運用の手順に組み込みます。

レベルAAは一度の改修だけで維持できる状態ではありません。
公開後の更新で見出し構造、代替テキスト、配色、フォームが変わるため、担当と確認時期を決めて繰り返し点検します。
運用体制の作り方は、公開後のWebアクセシビリティ運用でも整理しています。

公開前に確認するチェックリスト

• 対象ページと一連の操作を定義したか
• レベルAとレベルAAの達成基準を確認したか
• 通常時と各状態の文字コントラストを実測したか
• すべての機能をキーボードで操作でき、フォーカス位置を見分けられるか
• 見出し、ランドマーク、リスト、表を意味に沿って使っているか
• 入力欄にラベルがあり、エラーの場所、理由、直し方が伝わるか
• 自動検査だけで判定せず、手動検査を行ったか
• 未解決事項と再検査の時期を記録したか

AA準拠を進めるには、達成基準を個別の修正項目として消化するだけでなく、利用者が目的の操作を完了できるかをページ全体で確かめる必要があります。
対象の定義、実装、複数の方法による検査、変更後の再確認を一つの運用にしてください。

この記事に関連する株式会社greedenの取り組み

WCAG 2.1 AA対応は、部分修正だけでなく、現状確認と優先順位付けから始めると進めやすくなります。株式会社greedenは、Webアクセシビリティチェックと、文字サイズ変更やコントラスト調整などを追加できるUUUを提供しています。