EN / JA
UX & Marketing

アクセシビリティ vs. セキュリティ：視覚的CAPTCHAがWCAG基準を満たさない理由

· 1 min read

セキュリティチェックボックスが10億人を締め出す

世界保健機関によると、世界には何らかの視覚障害を持つ人が約13億人いる。世界人口の約16%だ。Webサイトがお問い合わせフォームに画像ベースのCAPTCHAを設置するたびに、潜在的なオーディエンスのかなりの部分にこう伝えていることになる。「あなたが人間であることを証明してください。ただし、見える方に限ります。」

これは仮定の問題ではない。2000年代初頭に設計され、現代のWebに適切に対応することなく放置されたセキュリティパラダイムの、測定可能で十分に文書化された失敗だ。Webアクセシビリティとボット防御の間の対立は20年以上にわたる未解決の問題であり、画像選択CAPTCHAは最悪の加害者だ。

Webサイトを構築するなら、どこに線があるのか、法律が実際に何を定めているのか、どんな技術的代替手段が存在するのかを理解する必要がある。本記事ではそれを解説する。

問題：CAPTCHAはそもそも全ての人のために設計されていなかった

画像CAPTCHAの仕組み（と排除される人々）

全ての画像CAPTCHAの前提はシンプルだ。人間には解けるが機械には解けない視覚的チャレンジを提示する。信号機を全て選べ。自転車のある四角をクリックせよ。店舗を特定せよ。

このモデルはユーザーが以下の能力を持つことを前提としている：

  • 表示された解像度で画像をはっきりと見えること
  • ノイズの多い低品質な写真の中で色やオブジェクトを識別できること
  • 正確なポインター入力でグリッドインターフェースを操作できること
  • 遅い操作にペナルティを課す制限時間内にタスクを完了できること

これらの前提のそれぞれが、特定のユーザーカテゴリ全体を排除する：

前提 排除されるユーザー
明瞭な視力 全盲のユーザー、ロービジョンのユーザー、白内障や緑内障のユーザー
色・オブジェクトの識別 色覚異常のユーザー、認知障害のあるユーザー
正確なポインター入力 キーボードナビゲーション、スイッチデバイス、音声操作に頼るユーザー
速度 運動障害のあるユーザー、高齢者、支援技術を使用するユーザー

スクリーンリーダーはCAPTCHA画像を意味のある形で説明できない。altテキストは意図的にあいまいであるか存在しない。説明的なaltテキストを提供すればチャレンジの意味がなくなるからだ。ここに構造的かつ本質的な矛盾がある。このセキュリティ機構は、アクセシブルでないことでのみ機能する。

音声フォールバックは本当の解決策ではない

ほとんどのCAPTCHAプロバイダーは音声の代替手段を提供している。しかし実際には、これらの音声チャレンジは：

  • 音声テキスト変換ボットを防ぐためにひどく歪められている
  • 多くの実装では英語のみで提供され、非英語話者を排除する
  • 重ねられたバックグラウンドノイズにより、聴覚障害のないユーザーにとっても困難である
  • 自動再生の制限により、一部のモバイルブラウザでは利用不可となる

スタンフォード大学とカーネギーメロン大学の研究では、音声CAPTCHAは障害のないユーザーでも50%を超える失敗率があることが一貫して示されている。騒がしい環境でスクリーンリーダーに頼るユーザーにとって、その体験は事実上壊れている。

5分でできるアクセシビリティテスト

現在のフォームがアクセシブルかどうか確信が持てない場合は、今すぐ5分以内でテストできる：

  1. キーボードテスト： マウスのケーブルを抜く（または横に置く）。Tab、Space、Enterキーのみを使って、お問い合わせフォームに移動し、入力し、CAPTCHAを解き、送信ボタンを押すことができるか試してほしい。CAPTCHAウィジェットからフォーカスが抜け出せなくなったら、テストは失敗だ。
  2. スクリーンリーダーテスト： OSに組み込まれているスクリーンリーダー（MacのVoiceOver、WindowsのナレーターやNVDA）をオンにする。目を閉じてフォームを送信してみてほしい。CAPTCHAがあなたに何を求めているか理解できるだろうか？

あなたのフォームがこれらのどちらかに失敗しているなら、それは正当なユーザーをサイトから追い出しているということだ。

技術的詳解：WCAGと法律

WCAG 2.1と4つの原則

Web Content Accessibility Guidelines（WCAG）2.1はW3Cが発行したもので、POURとして知られる4つの原則でWebアクセシビリティを定義している：

  1. 知覚可能（Perceivable） — 情報は全てのユーザーが知覚できる方法で提示されなければならない
  2. 操作可能（Operable） — インターフェースコンポーネントは全ての入力方法で使用可能でなければならない
  3. 理解可能（Understandable） — コンテンツとコントロールは理解可能でなければならない
  4. 堅牢（Robust） — コンテンツは現在および将来の支援技術で動作しなければならない

画像CAPTCHAは、1.1.1 非テキストコンテンツ、2.1.1 キーボード、4.1.2 名前、役割、値など、複数の達成基準に違反する。しばしばキーボードフォーカスをトラップし、支援技術に対して自身の状態を正しく公開しない。

アメリカでは、障害を持つアメリカ人法（ADA）第3編がWebサイトにも適用されると裁判所が解釈しており、毎年何千件ものデジタルアクセシビリティ訴訟が起きている。EUでは、European Accessibility Act（EAA）が2025年6月に全面施行され、デジタルサービスに厳格な基準（EN 301 549）の遵守を求めている。真にアクセシブルな代替手段を持たないセキュリティツールを使用することは、明らかなコンプライアンスのギャップを残すことになる。

最新の代替手段：reCAPTCHA v3、Turnstile、hCaptcha

業界は視覚的なパズルから離れつつある。GoogleのreCAPTCHA v3やCloudflareのTurnstileは、目に見えない行動スコアリングを使用してユーザーを検証する。

これらは非常に強力なツールであり、正しく設定すれば強固なスパム対策となる。アクセシビリティの観点でも大きな前進だ。しかし、「すべてをサードパーティのスクリプトに依存する」ことには、環境によっては以下のトレードオフを考慮する必要がある：

  • プライバシーの懸念： これらは外部のスクリプトを読み込む。例えばreCAPTCHA v3は行動データを追跡するため、GDPRを厳格に遵守したいEU圏のサイトなどでは懸念が生じるケースがある。
  • 不透明なスコアリング： アルゴリズムはブラックボックスだ。支援技術を使用するユーザーは標準とは異なるインタラクションパターンを示す可能性があり、誤って「ボット」としてフラグ付けされるリスクがゼロではない。
  • 予期せぬフォールバック： これらのサービスの一部は、スコアが境界線上の場合、依然として視覚的チャレンジ（画像選択など）を提示することがある。

解決策：パッシブなサーバーサイド・セキュリティ

最もアクセシブルなセキュリティとは、ユーザーがその存在に気づかないセキュリティだ。外部スクリプトに依存せず、サーバーサイドでの多層的なアプローチを用いることで、既存のセキュリティを補完、あるいは代替する優れたスパム対策を実現できる。

1. ハニーポットフィールド

ハニーポットは、人間のユーザーには見えないがDOMを解析するボットには見えるフォームの隠しフィールドだ。フィールドに入力があれば、サーバーはその送信を拒否する。ユーザーのインタラクションは不要で、aria-hidden="true"を使用することでスクリーンリーダーからも隠される。

自分で試してみたいだろうか？ カスタムHTMLフォームに追加できる基本的な実装例は以下の通りだ：

<!-- HTML -->
<div class="hp-wrapper" aria-hidden="true">
  <label for="website_url">このフィールドは空のままにしてください</label>
  <input type="text" id="website_url" name="website_url" tabindex="-1" autocomplete="off">
</div>

<style>
/* CSS */
.hp-wrapper {
  position: absolute;
  left: -9999px; /* display:none を使わずに視覚的ユーザーから隠す */
}
</style>

2. クライアント側のProof-of-Work (PoW)

PoWは、フォーム送信が受け付けられる前に、ブラウザに小さな計算パズル（例：Web Crypto APIを使って特定のプレフィックスを持つハッシュを見つけるなど）を静かに解かせる手法だ。目に見えず、ボットネットに計算コストを課し、ユーザーの入力は一切不要だ。

3. 時間ベースの分析

ボットはフォームをミリ秒単位で入力・送信する。ページ読み込みから送信までの時間を計測することで、信頼性の高いシグナルが得られる。3秒未満の送信は非常に疑わしく、1秒未満であればほぼ間違いなくボットだ。

見えないセキュリティの限界

完全な透明性を期すために言えば、完璧なシステムは存在しない。この目に見えないスタックの弱点は何だろうか？

  • 標的型攻撃： あなたのWebサイトを標的としてカスタムボットを書く開発者は、コードを検査して基本的なハニーポットを迂回することができる。
  • 処理のオーバーヘッド： Proof-of-Workはわずかな計算負荷を追加する。極端に古い、または低スペックのデバイスでは、送信時間にほんの数ミリ秒の遅れが生じる可能性がある。

しかし、一般的なWebスパムの99%（自動化された大量送信スクリプトに依存するもの）に対しては、これらの手法を組み合わせることで信じられないほどの効果を発揮する。

実践への適用：多層防御か、スタンドアロンか

動的ハニーポット、バックグラウンドでのPoW、そして時間分析。これらのメソッドを重ねることで、摩擦を追加することなくスパムをブロックする堅牢な防御を構築できる。

ユーザーがページを読み込む -> トークン + PoWチャレンジが生成される
ユーザーがフォームに入力 -> ブラウザが静かにPoWを解く
ユーザーが送信する -> サーバーがトークン、PoW、ハニーポット、経過時間を検証
結果 -> スパムはブロックされ、ユーザーの摩擦はゼロ。

スタックに適したツールの選択
大規模なエンタープライズアプリケーションを運用しているなら、reCAPTCHAやTurnstileといったサービスが適している。カスタムWebアプリを開発しているなら、上記で説明したサーバーサイドのロジックと基本のハニーポットを実装するのが効果的だ。

もしWordPressとContact Form 7を利用しているなら、この目に見えないスタックを正確に処理する無料でオープンソースのツールがある。Samurai Honeypot for Forms だ。

このプラグインは、AkismetやreCAPTCHAなど既存の対策と「共存」させて多層防御の最後の砦として使うこともできれば、GDPR準拠やサイトの表示速度を極限まで高めたい場合に単体の軽量な防衛網として使うこともできる。
外部サーバーにデータを送信せず、あなたのサーバー内だけで判定が完結するプライバシーセーフな設計となっているため、現在のセキュリティ環境を邪魔せずに安全性を底上げすることが可能だ。

まとめ

問題は、CAPTCHAをアクセシブルにできるかどうかではない。できない——少なくとも機構そのものを損なわずには。問題は、CAPTCHAにすべてを依存し続ける必要があるかどうかだ。

見えない、パッシブなバリデーションは、排除されるユーザーをゼロに保ちながら、優れたスパム対策を提供する。Webアクセシビリティはプロジェクトの最後にボルト留めする機能ではない。ベースラインの要件だ。サイトに追加するセキュリティレイヤーも同じ基準を満たすべきだ。全員を守り、誰も排除しない。

参考文献：
– W3C: Inaccessibility of CAPTCHA — CAPTCHAが根本的に問題をはらんでいることに関するW3C自身の分析
– WCAG 2.1 Quick Reference — 達成基準とテクニックの完全なリスト
– WebAIM Million Report — 上位100万サイトのアクセシビリティエラーに関する年次分析

← すべてのコラム