2024年4月の障害者差別解消法改正により、ECサイトのアクセシビリティ対応は「努力義務」から事実上の必須要件に。何をすべきかを解説します。

改正法の正式名称は「障害を理由とする差別の解消の推進に関する法律」（平成25年法律第65号）。2024年4月1日施行の改正により、民間事業者にも「合理的配慮の提供」が義務化されました。

このチェックリストの使い方

以下の8項目はWCAG 2.2（Web Content Accessibility Guidelines）の基準に基づいています。各項目にWCAG基準番号を併記しているので、公式ガイドラインの該当箇所を参照しやすくなっています。

1. 全画像にalt属性を設定する

WCAG基準: 1.1.1 Non-text Content（レベルA） なぜ重要か: スクリーンリーダー（NVDA, VoiceOver, JAWS等）は画像のalt属性を読み上げます。altが空の商品画像は「画像」としか読み上げられず、視覚障害のあるユーザーが商品を理解できません。 ECサイトでの実装ルール: テストツール: axe DevTools（Chrome拡張、無料）でalt属性の欠落を自動検出。

---

2. カラーコントラスト比を4.5:1以上にする

WCAG基準: 1.4.3 Contrast (Minimum)（レベルAA） なぜ重要か: テキストと背景のコントラスト比が低いと、色覚異常や弱視のユーザーだけでなく、屋外でスマホを見ている一般ユーザーも読みにくくなります。 基準値: | テキストサイズ | 最低コントラスト比 | 推奨コントラスト比 | |--------------|-------------------|-----------------| | 通常テキスト（14px〜） | 4.5:1 | 7:1（レベルAAA） | | 大きなテキスト（18px〜 or 14px太字〜） | 3:1 | 4.5:1 | テストツール: WebAIM Contrast Checkerにテキスト色と背景色を入力 → 合否判定。 よくある違反: 薄いグレーの注意書き（#999 on #fff = 2.85:1 → NG）。最低でも #767676（4.54:1）以上を使うこと。

---

3. フォーム要素にlabel要素を関連付ける

WCAG基準: 1.3.1 Info and Relationships（レベルA）/ 4.1.2 Name, Role, Value（レベルA） なぜ重要か: が関連付けられていないフォーム要素（入力欄、セレクトボックス等）は、スクリーンリーダーが「テキストフィールド」としか読み上げず、何を入力すべきかわかりません。 正しい実装: 
<!-- label の for 属性と input の id を一致させる -->
<label for="email">メールアドレス</label>
<input type="email" id="email" name="email" required>


<!-- プレースホルダーはlabelの代替にならない -->
<!-- ❌ 悪い例 -->
<input type="email" placeholder="メールアドレス">

ECサイトの重要フォーム: 会員登録、ログイン、カート、チェックアウト、お問い合わせ。特にチェックアウトフォームの未対応は購入機会の損失に直結。

---

4. キーボードナビゲーションを確保する

WCAG基準: 2.1.1 Keyboard（レベルA） なぜ重要か: マウスを使えないユーザー（運動機能障害、スクリーンリーダー利用者）はTabキーでページを操作します。全てのインタラクティブ要素がキーボードでアクセスできる必要があります。 テスト方法: - 全てのリンク・ボタンにTabでフォーカスが当たるか - フォーカスの順序は論理的か（左上→右下、見た目の順序と一致） - モーダル/ダイアログが開いた時にフォーカスが移動するか - ハンバーガーメニューがキーボードで開閉できるか ECサイト固有の注意: カートの「数量変更」「削除」ボタン、商品画像のズーム、カラーバリエーションの選択がキーボードで操作できるか。

---

5. ページの言語を宣言する

WCAG基準: 3.1.1 Language of Page（レベルA） なぜ重要か: がないと、スクリーンリーダーがページの言語を判定できず、日本語テキストを英語の発音規則で読み上げてしまいます。 実装（1行追加するだけ）: 
<html lang="ja">
多言語対応時: ページ内に部分的に英語が含まれる場合 → Made in Japan テストツール: HTML Validatorで lang 属性の有無を自動チェック。

---

6. フォーカスインジケーターを視認可能にする

WCAG基準: 2.4.7 Focus Visible（レベルAA）/ 2.4.11 Focus Not Obscured（レベルAA、WCAG 2.2 新基準） なぜ重要か: Tabキーでフォーカスが当たっている要素が視覚的にわかないと、キーボードユーザーは今どこにいるか把握できません。 よくある問題: CSSで outline: none を設定してフォーカスリングを消している。 正しい実装: 
/ デフォルトのフォーカスリングを消さない。カスタマイズする場合は: /
:focus-visible {
  outline: 3px solid #4A90D9;
  outline-offset: 2px;
}


/ マウスクリック時は非表示、キーボード操作時のみ表示 /
:focus:not(:focus-visible) {
  outline: none;
}

---

7. タッチターゲットのサイズを44×44px以上にする

WCAG基準: 2.5.8 Target Size (Minimum)（レベルAA、WCAG 2.2 新基準） なぜ重要か: モバイルECでタップ対象が小さすぎると、運動機能障害のあるユーザーだけでなく、一般ユーザーの誤タップも増えます。 基準: ECサイトでよくある違反: 
/ タッチターゲットの最低サイズを保証 /
.btn, a, button, input, select {
  min-height: 44px;
  min-width: 44px;
}

---

8. エラーメッセージを具体的に提示する

WCAG基準: 3.3.1 Error Identification（レベルA）/ 3.3.3 Error Suggestion（レベルAA） なぜ重要か: 「入力エラーがあります」だけでは、どのフィールドが間違っているかわかりません。具体的なフィールド名と修正方法を提示する必要があります。 良い例: 
<div role="alert" aria-live="polite">
  <p>以下のエラーを修正してください:</p>
  <ul>
    <li><a href="#email">メールアドレス: 「@」の後にドメイン名を入力してください</a></li>
    <li><a href="#phone">電話番号: ハイフンなしの数字のみで入力してください</a></li>
  </ul>
</div>
悪い例: 
<p style="color: red;">入力エラーがあります。</p>
ECサイトの注意: チェックアウトフォームでのエラーは直接カート放棄につながります。バリデーションエラーは入力中にリアルタイムで表示するのがベスト。

---

まとめ

8項目のチェックリストを順番に対応することで、WCAG 2.2 レベルAA準拠への道筋が見えます。

まず今日やるべき3つ: ① の確認 ②商品画像のalt属性チェック ③カラーコントラスト比の確認。この3つは5分で完了します。

アクセシビリティ対応は法的リスク軽減だけでなく、SEO（alt属性、構造化マークアップ）やCRO（フォームUX改善）にも直結します。

自社サイトの現状を確認するには、Pulse DigitalのChrome拡張で診断してみてください。WCAG基準のアクセシビリティ問題をワンクリックで検出できます。