ARIA-Barriers

認知機能テストとしての認証

2026年09月02日

はじめに

最近、ウェブサービスのログイン認証で「メールに届いた画像の内容を選ぶ」方式を見かけます。

実装によっては WCAG の複数の達成基準に適合しません。

デモを作ったので、ぜひ体験してください。ただし、架空の例を題材にしており、特定のサービスの UI を再現しているわけではありません。

また、本記事は筆者個人の解釈です。正式な適合判断や法的助言ではありません。

認証の流れ

  1. ユーザーがパスワードを入力します
  2. メールに認証コードが届きます
  3. メールには「画像1の内容：ねこ」「画像2の内容：いぬ」などと書かれています
  4. 認証画面で4つの画像ボタンから、メールに書かれた2つを選びます
  5. 有効期限は2分です

メール自体はテキストで読めます。問題は、認証画面の画像に代替テキストがあるかどうかだけではありません。メールで示された内容を記憶し、認証画面で画像やボタンから探し出して選択する「記憶・転記」という認知負荷も生じています。

デモ

3つのパターンを比較できるデモを作りました。

認証コードのお知らせ（メール）の表示、非表示の切り替えができます。その下の悪い例A・悪い例B・いい例をタブで切り替えられます。有効期限のタイマーがあります。

別窓でデモを開く

悪い例A

認証画面のボタンは画像だけで、alt も視覚的ラベルもありません。スクリーンリーダー利用者には、4つのボタンが「ボタン」としか読み上げられないケースがあります。どれが「ねこ」なのかわからず、2つ選ぶことも困難です。

実装や OS、ブラウザ、スクリーンリーダーの組み合わせによっては、画像や絵文字に自動でラベルが付くこともあります。ですが、絵の解釈は人によって異なりますし、AIの自動ラベルが誤認識することもあります。

さらに2分で期限が切れ、延長や警告もありません。

悪い例B

画像選択（alt なし）に加えて、テキスト入力の代替手段を置いています。よくある誤解として、「テキスト入力があるので 3.3.8 の『代替手段』例外を満たし、さらに画像認証は CAPTCHA に当たるから 1.1.1 も alt なしで OK ではないか」というものがあります。

しかし、今回の認証は本人確認のための多要素認証（2要素認証）であり、人間とボットを区別する CAPTCHA ではありません。1.1.1 の CAPTCHA 例外は「人間とコンピュータを判別する目的」に限られ、本人確認の認証には適用されません。したがって画像ボタンには通常通り accessible name（アクセシブルな名前、支援技術に読み上げられる名前）が必要です。

結果として、テキスト入力の代替手段は 3.3.8 の『代替手段』例外を満たす可能性がありますが、画像ボタン自体の 1.1.1 は満たしていません。

いい例

ボタンに aria-label="ねこ" などを付け、視覚的にも「ねこ」と表示します。画像は装飾的なので alt は空にし、可視テキストと accessible name が重複して読まれないようにします。スクリーンリーダー利用者には「ねこ ボタン」と読み上げられます。時間延長ボタンも置きます。

ただし、記憶・転記の負荷は残ります。

該当する達成基準

1.1.1 非テキストコンテンツ

認証画面では画像が使われています。画像には意味があり、テキストによる代替が必要です。alt 属性や視覚ラベルがない場合、スクリーンリーダー利用者は内容を知ることができません。

なお、今回のような本人確認の認証は CAPTCHA ではありません。1.1.1 の CAPTCHA 例外は、人間とボットを区別する目的で用いられる非テキストのテストに限られます。本人確認の多要素認証にその例外を適用することはできません。

また、画像認証が 1.1.1 の『テスト』例外（テキストで提示すると無効になるテスト）に該当する可能性も議論されます。ただし、その例外であっても『少なくともその非テキストコンテンツを識別できるテキストによる代替』が必要であり、画像ボタンの accessible name を空にしてしまうことは認められません。テキスト入力の代替手段を用意した悪い例Bも、画像ボタン自体の accessible name がないため、多要素認証としての 1.1.1 には適合しません。

2.2.1 タイミング調整可能

時間制限がある場合、解除・調整・延長のいずれかが必要です。制限時間が固定で警告や延長もない認証は、この達成基準を満たしません。WAIC-TEST-0121-01 では、制限時間が切れようとしていることを利用者に警告するスクリプトを提供しています。

OTPの有効期限として時間制限は設けられていますが、ユーザーが複数の選択肢を検討し、間違えて再選択し、操作を完了するには十分な時間ではありません。特に画面読み上げユーザーは、ラベル読み上げに時間がかかるため、実質的な操作時間がさらに短くなります。

3.3.8 アクセシブルな認証（最低限）

WCAG 2.2 で追加された達成基準です。認証プロセスで認知機能テストを要求してはなりません。ただし、代替手段・メカニズム・物体の認識・個人特有のコンテンツの場合は例外です。

今回のデモは「記憶・転記」を伴う認知機能テストです。画像選択そのものは 3.3.8 の「物体の認識」例外に該当する可能性がありますが、メール内容の転記部分は別の認知負荷として問題になります。

画像を採用する理由として、「文字や数字より覚えやすい」という設計上の意図も考えられます。ただし、覚えやすさは認知機能テストを相殺しません。画像の内容を識別し、メールのテキストと対応させる作業自体が認知負荷になり、読解レベルの問題（達成基準 3.1.5）ではなく認知機能テスト（3.3.8）の問題として扱われます。

より厳格な 達成基準 3.3.9: アクセシブルな認証（高度） では、「物体の認識」及び「個人特有のコンテンツ」の例外がなく、画像認証そのものが認められにくくなっています。

現行の JIS X 8341-3:2016 は WCAG 2.0 に準拠しており、3.3.8 は含まれていません。しかし次期 JIS 改正では WCAG 2.1 や 2.2 の追従が想定され、画像や絵文字で認証する方式は明確に問題になります。2024年4月1日の改正障害者差別解消法による合理的配慮の義務は、JIS のバージョンに依存せず、障碍を理由に個別に支援が求められた際の対応として考慮されます。

合理的配慮の義務と代替認証手段の提供は、セキュリティリスク評価と分離して考えることはできません。障碍を理由に個別に支援が求められた際、代替手段が既存方式より安全でない場合、事業者はセキュリティリスクとアクセシビリティの両方を管理する複雑な判断を迫られます。セキュリティ専門家とアクセシビリティエンジニアの共同作業が必要です。

ボット対策との関係

認証を複雑にすれば安全になる、と一見思われがちです。しかし、画像のラベルを隠したり、ユーザーにメール内容の記憶・転記を強いたりしても、最新のボットは画像認識や DOM 解析で容易に破ることができます。具体的には、光学文字認識（OCR）、機械学習ベースの画像分類、大規模言語モデルを用いた画像理解などが使われ、ユーザーの視覚的な選択タスクを機械が再現可能になっています。人間と機械の識別は、もはや画像認識の複雑さでは実現できません。結果として、被害を受けるのはスクリーンリーダー利用者や認知負荷の高い人だけになりかねません。

認知機能テストは画像を使わなくても発生します。「エー・ビー・シー」と画面や音声で提示して ABC と入力させる場合も、聞き取った内容を変換し、記憶して転記する負荷になります。

ボット対策はレート制限、パスキー（FIDO2 / WebAuthn）、機械学習ベースの検知などで行うべきで、認証 UI のラベルを隠すのは誤ったトレードオフです。

認証コード自動入力

認証を画像選択ではなく数字や文字列にしても、メールに届いたコードを確認してコピー＆ペーストする手順は依然として認知負荷になります。ここでも新しい技術動向があります。

iOS では、SMS の確認コードをキーボード候補から自動入力する機能が iOS 12（2018年）から搭載されており、iOS 17（2023年）からは Apple 純正の「メール」アプリに届いた確認コードにも対応しています。iOS 26（2025年）では、この OS の確認コード自動入力（AutoFill）の対象が Gmail などサードパーティ製アプリへ拡張されました。これは Gmail 側の機能ではなく OS 側の機能拡張で、特定サービスとの個別連携ではなく、OS がアプリに届いた確認コードを検出する仕組みです（Apple による公式告知はなく、ベータ版で発見されたと報道されています）。スマートフォンでは、メールからの転記負荷を減らす方向が長期にわたって進んでいます。

Google は Chrome で「Gmail OTP Autofill」機能を開発しています。Gmail にログインした同一プロファイルで、サイトの OTP 入力欄にメールの確認コードを提案するものです。ただし公式の製品発表はなく、一次情報は Chromium のソースコードとコミットです。

なお、これら技術はサイト側の実装の影響を受けます。たとえブラウザや OS が自動入力を提案しても、入力欄が貼り付けを拒否したり、パスワードマネージャーや自動入力を妨げたりしていれば、ユーザーは支援を受けられません。3.3.8 で想定される「メカニズム」は、コンテンツ側がコピー＆ペーストや自動入力を妨げないことが前提です。また、スクリーンリーダー利用者にとって自動入力がどう通知されるか、手動確認が不要かどうかは要注意です。

自動入力は転記負荷を減らす一方、認証コードの扱いが OS やブラウザの自動入力機能に委ねられるという新たな考慮点が生じます。コードが正当なドメインにだけ提示されるか、悪意あるアプリが自動入力 UI やクリップボードを読めないか、といった点が重要です。利用者の便益と引き換えに、攻撃面の性質が変わることも視野に入れるべきです。

まとめ

メールではテキストで書かれた認証コードが、認証画面では画像だけで提示されると、スクリーンリーダー利用者は操作できません。時間制限も加わると、1.1.1、2.2.1、3.3.8 の複合的な失敗例になります。

改善策は以下の通りです。

筆者の所感

以下は筆者個人の思い入れです。

達成基準への適合・準拠は目的ではありません。認証に関する達成基準は、支援技術だけでなく、ユーザーの認知負荷や操作性への理解も求めています。見落とされがちですが、達成基準の上位にはガイドラインと原則があります。これらが要件定義に反映され、技術動向を踏まえて正しく実装されれば、より多くのユーザーが自立して認証を完了できるようになり、アクセシビリティ試験結果がその客観的なエビデンスになると考えます。

参考文献