アクセシビリティと同意が今重なり合う理由

GDPRは、バナーを見てクリックできる人だけでなく、すべてのユーザーから同意を得られることを要求しています。欧州データ保護委員会は、データ主体がサイトに対応されていない障害のために同意インターフェースと有意義に対話できない場合、同意は有効に取得されていないと明確にしています。つまり、クッキーはそもそも読み込まれるべきではなかったということです。

アクセシビリティの面では、EU加盟国全体で国内法に取り込まれた欧州アクセシビリティ法（EAA）により、消費者サービスを提供する民間セクターのウェブサイトおよびアプリに対してWCAG 2.1 AAが最低基準となっています。ペナルティ制度は国によって異なりますが、通常は違反1件あたり5万ユーロから50万ユーロの範囲で、継続的な非準拠については市場撤退命令も追加されます。

クッキーバナーの主要WCAG要件

キーボード操作性

すべてのバナーコントロール（承認、拒否、設定の管理、閉じる）は、キーボードのみで到達・操作できなければなりません。ユーザーはTabキーで論理的な順序でボタンを移動し、EnterまたはSpaceで有効化できる必要があります。フォーカスは背景に対して最低3:1のコントラスト比で視覚的に確認できる必要があります。

モーダルバナーにおけるフォーカストラップ

バナーがページの他の部分との対話をブロックしている場合、ユーザーが選択するまでキーボードフォーカスはバナー内に閉じ込められなければなりません。ユーザーはTabキーでバナーから出て下層のページをスクロールできてはなりません。フォーカスが閉じ込められていてバナーが閉じるときは、フォーカスはバナーをトリガーした要素か適切なデフォルト位置に戻る必要があります。

スクリーンリーダーのアナウンス

バナーはアクセシブルな名前とロールを持つダイアログとしてアナウンスされなければなりません。`role="dialog"` または `role="alertdialog"` を使用し、`aria-labelledby` をバナーの見出しに向け、`aria-describedby` を説明文に向けます。

色のコントラスト

本文テキストは背景に対して4.5:1のコントラストを満たす必要があります。大きなテキスト（18pt以上または14ptの太字）は3:1が必要です。ボタンテキスト、アイコン、フォーカスインジケーターにはそれぞれのコントラスト最低値があります。白背景の薄いグレーの「拒否」ボタンは、監査で見られる頻繁なWCAG不合格例です。

色だけに依存しない手がかり

承認と拒否を区別するために色だけに頼らないでください。色覚障害のあるユーザーがボタンを区別できるよう、異なるラベル、アイコン、または形状を使用します。

ダークパターンとアクセシビリティ

WCAG 2.2はダークパターンを直接対象とする新しい基準を導入しています。同意にとって特に関連性があります：

• 3.3.8 アクセシブル認証 — 同意の障壁として認知的パズルを禁止します。
• 3.3.7 冗長な入力 — 同意を撤回するだけのために情報を再入力させてはなりません。
• 2.4.11 フォーカスが隠れない — バナー自体がその後ろの要素のフォーカスインジケーターを隠してはなりません。
• 2.5.7 ドラッグ操作 — バナーがドラッグで承認する操作を使用する場合、シングルポインターの代替手段が存在しなければなりません。

RTLと国際化

アクセシビリティは右から左へ書く言語（アラビア語、ヘブライ語、ペルシャ語、ウルドゥー語）とスクリーンリーダーの発音にも及びます：

• 文書言語がRTLの場合、バナーに `dir="rtl"` を設定します。これによりボタンの順序とフォーカスの流れが読み方向と一致します。
• 翻訳されたバナーコピーに正しい `lang` 属性を使用します。これによりスクリーンリーダーが正しい音声学で単語を発音します。
• アイコンをミラーリングします — シェブロン、矢印、進捗インジケーターはRTLロケールでは反転する必要があります。

WCAG準拠のためのバナーテスト

単一のツールに頼らないでください。自動スキャンと実際の支援技術テストを組み合わせてください：

• axe DevTools または Lighthouse — WCAG不合格の約30〜40%を自動的に検出します。
• Windows上のNVDA または JAWS、Mac/iOS上のVoiceOver、Android上のTalkBack — 実際のスクリーンリーダーでテストします。スクリーンリーダーだけを使用してバナーをアナウンス、ナビゲート、閉じることができますか？
• キーボードのみのナビゲーション — マウスを抜いてください。承認、拒否、設定の管理ができない場合、キーボードユーザーも同様にできません。
• 色覚障害シミュレーション — Chrome DevToolsには組み込みの視覚障害シミュレーターがあります。第1色覚異常、第2色覚異常、第3色覚異常の状態で承認と拒否が区別できるか確認します。
• 400%ズーム — WCAGは水平スクロールなしに400%ズームでコンテンツが使用可能であることを要求しています。固定位置バナーはこのテストで失敗することが多いです。

よく見られるアクセシビリティの問題

• 歯車アイコンの後ろに隠れた拒否 — ダークパターンかつアクセシビリティ問題（アイコンボタンにアクセシブルな名前がない）。
• フォーカスがバナーに到達しない — 視覚的な注意を引くがTab順序でスキップされるバナー。
• フォーカストラップのないモーダルバナー — バナーが対話をブロックしていると主張しながら、ユーザーが背景ページにTabできる状態。
• 設定変更時に `aria-live` がない — スクリーンリーダーユーザーが選択が保存されたという確認を聞けない。
• `lang` 属性のない翻訳バナー — スクリーンリーダーがスペイン語のコピーを英語の音声学で発音する。

FlexyConsentがアクセシビリティをどのように実現するか