WCAG 3.3.9: アクセシブルな認証（強化版）

この規定の意味

WCAG 3.3.9 — Accessible Authentication (Enhanced) は、WCAG 3.3.8（Accessible Authentication — Minimum, AA）のAAAレベルに相当する基準です。これらはセットとして、WCAG 2.2で導入された一対の基準であり、ウェブサイトやアプリケーションに対して本人性を証明するプロセスそのものがアクセシビリティ上の障壁にならないようにすることを目的としています。

AAAレベルでは、3.3.9によって要件が大幅に厳格化されます。この基準は次のように定めています。認証プロセスのいかなるステップにおいても、以下のいずれかを提供しない限り、認知機能テストを要求してはならない：認知機能テストに依存しない代替の認証方法が提供されていること／ユーザーが認知機能テストを完了するのを支援するメカニズムが利用可能であること／認知機能テストが物体の認識であること。 重要なのは、AA版（3.3.8）とは異なり、AAA基準では非物体コンテンツの認識を許容していた例外が削除されている点です（たとえば、ユーザーが以前に選択した非物体アイテムの画像など）。このレベルでは、真の物体認識、すなわち猫、自転車、家といった現実世界の一般的な物体の画像を認識することだけが認知機能テストとして許容されますが、それも他の条件が満たされていない場合に限られます。

認知機能テストとは、ユーザーに情報を記憶させる、操作させる、または書き写させることを要求するあらゆるタスクと定義されています。これには、ユーザー名やパスワードを覚えること、数学的なパズルを解くこと、歪んだテキストを判読するCAPTCHAを完了すること、個人の履歴に関するセキュリティ質問に答えること（例：「最初のペットの名前は？」）、文字列を順番に書き写すことなどが含まれます。これらはすべて、多くのユーザーが確実に行うことができない記憶や書き写しのタスクです。

合格とみなされるもの： 認証ステップが3.3.9に合格するのは、そのステップがいかなる認知機能テストも要求しない場合、または次の条件のいずれかを満たす場合です。(1) 完全に別の、認知機能を必要としない認証経路が提供されている（例：メールで送信されるマジックリンク、WebAuthn/パスキー、生体認証ログイン）；(2) テストの完了を支援するメカニズムがある（例：ブラウザのパスワードマネージャーがブロックされていない、コピー＆ペーストが許可されている）；(3) 関与する唯一の認知テストが、画像の集合から現実世界の一般的な物体を認識することだけである。

不合格とみなされるもの： バイパスや代替手段なしに、ユーザーにパスワードを記憶から思い出させる、貼り付け不可のコードを書き写させる、代替手段のない視覚または音声CAPTCHAを解かせる、知識ベースのセキュリティ質問に答えさせる、あるいは代替認証経路なしに非物体コンテンツ（抽象的な形や個人写真など）の事前に選択した画像を識別させるようなフローはすべて不合格です。

公式の例外： WCAG仕様自体が、物体の認識（現実世界のものの写真）が、このAAAレベルで許可される唯一の画像認識タスクであると明記しています。AA基準（3.3.8）では、「非物体」の個人的に選択された画像の認識も許容されていましたが、3.3.9ではこの例外が完全に削除されています。「広く使われている」認証パターンに対する例外は存在しません。もしパターンが代替なしに認知テストを要求するなら、それは3.3.9に不適合です。

なぜ重要か

認証は、多くの場合、ユーザーがデジタルサービスと行う最初の意味のあるインタラクションです。そのインタラクション自体がアクセシブルでなければ、サイトのその他のアクセシビリティは無意味になります — ユーザーはそもそも「入口」にたどり着けません。WCAG 3.3.9はこの障壁に直接対処しており、その影響は幅広い障害当事者グループに及びます。

認知障害のあるユーザー — 失読症、ADHD、外傷性脳損傷、認知症、学習障害などを含む — は、複雑なパスワードを記憶すること、時間制限付きのワンタイムコードを手作業で書き写すこと、歪んだCAPTCHAテキストを解読することが極めて困難、あるいは不可能な場合があります。世界保健機関は、世界人口のおよそ6人に1人が何らかの重大な障害を経験していると推計しており、その中でも認知障害はウェブアクセシビリティにおいて最大かつ最も支援が行き届いていないカテゴリの一つです。

運動機能障害のあるユーザー — パーキンソン病、本態性振戦、脊髄損傷、スイッチアクセスや視線入力技術を必要とする状態など — は、パスワードを正確に入力したり、コードを1文字ずつ書き写したりすることに苦労する場合があります。クリップボードの貼り付けをブロックすること（よくある不正対策ですが、実際には有害です）により、これらのユーザーは支援技術を使って1文字ずつ労力をかけて入力しなければならず、エラー率と疲労が大幅に増加します。

全盲またはロービジョンのユーザーは、スクリーンリーダーや拡大ツールに全面的に依存している場合があります。視覚的なCAPTCHAは、音声による代替がなければ完全にアクセス不能であり、音声CAPTCHAでさえ、聴覚障害や聴覚情報処理障害のあるユーザーにとっては非常に困難なことで知られています。「すべての信号機を選択してください」といった画像ベースのチャレンジも、画像の説明がない、あるいは誤解を招く場合には問題となり得ます。

ろう者や難聴のユーザーは、ワンタイムコードを電話でのみ提供する認証方法、特にSMSの代替がない音声通話のみの方法によって障壁に直面する可能性があります。

具体的な現実のシナリオ： 軽度の認知機能低下がある72歳のユーザーが、オンラインバンキングポータルにアクセスしようとしているとします。銀行は、ユーザー名（メールアドレスではなく、記憶しておかなければならない）、複雑なパスワード（クリップボードの貼り付けは禁止）、歪んだテキストを用いたCAPTCHAを要求しています。ユーザーはCAPTCHAに2回失敗し、アカウントがロックされ、銀行のヘルプラインに電話しなければならなくなります — 40分かかるプロセスです。もし銀行がパスキーやマジックリンクを実装していれば、このユーザーは数秒で認証を完了できたはずです。このようなシナリオは、ウェブ上で毎日何百万回も繰り返されており、完全に防ぐことが可能です。

障害の有無にかかわらず、アクセシブルな認証はすべてのユーザーに利益をもたらします。何億人もの人が利用しているパスワードマネージャーは、資格情報を貼り付けることができることを前提としています。貼り付けをブロックしたり、手動での書き写しを要求したり、アクセシブルでないCAPTCHAを組み込んだりすることは、一般のユーザーにとってもフラストレーションの原因となります。また、セキュリティの観点からも問題があります。複雑なパスワードを手入力させることは、ユーザーがより単純で弱いパスワードを選んだり、複数のサイトで使い回したりする可能性を高めます。推奨される代替手段であるパスキーやマジックリンクは、従来のパスワード＋CAPTCHAフローよりもアクセシブルであり、かつより安全です。

関連するAxe-coreルール

WCAG 3.3.9は、手動テストのみが必要な基準として分類されています。axe-core 4.10の時点では、この基準を完全に評価できる自動ルールは存在しません。自動ツールがこれらの違反を検出できない理由を理解するには、この基準が実際に何を測定しているのかを理解する必要があります。

• 手動テストが必要 — 認知機能テストの検出： 自動スキャナーは、<input type='password'> やサードパーティCAPTCHAウィジェットを埋め込んだiframeのような特定のHTML要素の存在を検出することはできますが、認証フロー全体がアクセシブルな代替なしに認知機能テストを要求しているかどうかを判断することはできません。この基準が対象としているのは、単一の要素の属性ではなく、複数のステップやページにまたがるユーザージャーニー全体です。スキャナーは、貼り付けがJavaScriptによってプログラム的にブロックされているかどうか、コード入力フィールドの時間制限が妥当かどうか、代替認証経路が本当に認知テストを回避しているかどうかを評価することはできません。これらは、実際の認証プロセスを人間の評価者が通しで確認する必要がある、振る舞いとアーキテクチャに関する問題です。
• 手動テストが必要 — 代替経路の検証： スキャナーがCAPTCHAウィジェットを検出できたとしても、同じページまたは同じフロー内にアクセシブルな代替認証方法が存在するかどうかを検証することはできません。「パスキーでサインイン」オプションが本当に同等なのか、それともアクセスするためにまずアクセシブルでないCAPTCHAを通過しなければならない二次的な設定ページに埋もれているのかを評価することもできません。代替経路の同等性を評価するには、それらの完全性と目立ち方について人間の判断が必要です。
• 手動テストが必要 — クリップボード貼り付けの挙動： pasteイベントを傍受してキャンセルするJavaScript（pasteリスナーでevent.preventDefault()を呼び出す）は、静的なHTML解析からは見えません。スキャナーには有効な<input>要素が見えるだけで、その要素への貼り付けが無効化されていることは分かりません。パスワードやコードを実際に貼り付けようとする手動テストだけが、この不具合を明らかにできます。
• 手動テストが必要 — 認証ウィジェットの支援技術との互換性： サードパーティの認証SDK（ソーシャルログインボタン、CAPTCHAプロバイダ、生体認証プロンプトなど）は、iframeやShadow DOM内にレンダリングされることがあり、自動スキャナーが完全に内部まで解析できない場合があります。NVDA、JAWS、VoiceOverといったスクリーンリーダーを用いた手動テストは、認証フロー内のすべてのインタラクティブ要素が操作可能で理解可能であることを確認するために不可欠です。

テスト方法

1. すべての認証入口ポイントを特定する： テストの前に、アプリケーション内でユーザーが認証または本人確認を行わなければならないすべての場所をマッピングします。これには、初回ログイン、アカウント作成、パスワードリセット、二要素認証プロンプト、セッションタイムアウト後の再認証、支払い確認画面、年齢確認ゲートなどが含まれます。これらのフローはそれぞれ個別に評価する必要があります。
2. 自動ベースラインスキャンを実行する： 各認証ページで、axe DevTools（ブラウザ拡張）またはChrome DevToolsのLighthouseを使用します。これらのツールは3.3.9の違反を直接フラグ付けすることはありませんが、フォームフィールドのラベル欠如、アクセシブルでないiframeコンテンツ、フォーカス管理の欠如など、認証の障壁を悪化させる関連問題を表面化させます。手動評価の文脈として、フラグ付けされた問題をメモしておきます。axe DevToolsでは、「Needs Review」タブに、手動判断が必要な項目が表示されます。
3. 認知機能テストの有無を監査する： 各認証ステップについて、「このステップはユーザーに(a)何かを覚えさせるか、(b)何かを書き写させるか、(c)パズルを解かせるか」を確認します。もし「はい」であれば、次のいずれかが存在し、かつ同等に目立つ形で提供されていることを確認します：認知機能を必要としない代替経路／貼り付け許可や自動入力に対応したフィールドなど、完了を支援するメカニズム／唯一の認知タスクが現実世界の一般的な物体の認識であること。
4. クリップボード貼り付けの挙動をテストする： 各パスワードおよびコード入力フィールドで、テキストをクリップボードにコピーし、Ctrl+V（Windows/Linux）またはCmd+V（macOS）で貼り付けを試みます。貼り付けがブロックされる場合は不適合です。また、ブラウザのパスワードマネージャーによる自動入力が抑制されていないか（autocomplete='off'や、フォーカス時に自動入力値をクリアするJavaScriptがないか）も確認します。
5. NVDA＋Firefoxでテストする： キーボードとNVDAスクリーンリーダーのみを使用して、認証フロー全体を操作します。すべてのフォームフィールドが意味のあるラベルとともに読み上げられること、すべてのインタラクティブなコントロール（ボタン、リンク、CAPTCHAチャレンジ）に到達でき操作可能であること、エラーメッセージが関連フィールドとプログラム的に関連付けられ、追加のナビゲーションを必要とせず即座に読み上げられることを確認します。
6. VoiceOver＋Safari（macOS/iOS）でテストする： 同じ認証フローを繰り返します。iOSでは、ネイティブ認証が使用されている場合に生体認証（Face ID / Touch ID）が代替手段として提供されていること、また生体認証が利用できない場合でも、ウェブベースのフローがスイッチコントロールのみで完全に操作可能であることを確認します。
7. JAWS＋Chromeでテストする： フローを繰り返し、特にサードパーティウィジェット（OAuthソーシャルログイン、CAPTCHA iframe）がどのように読み上げられるかに注意を払います。JAWSは一部のARIAパターンをNVDAとは異なる方法で処理するため、両方でのテストが必要です。
8. 代替経路の真の同等性を評価する： 代替認証方法（例：「マジックリンクでサインイン」）が存在する場合、その代替のみを用いてフロー全体を完了します。いかなる認知テストも要求されることなく、同じ認証済み状態に到達できることを確認します。代替経路自体にCAPTCHAや記憶テストが含まれている場合、それは3.3.9における有効な代替とはみなされません。
9. 証拠とともに結果を文書化する： 各不具合について、どのステップがどのような理由で不適合となるのかを示す画面録画または注釈付きスクリーンショットを取得します。この文書化は、開発チームへの修正依頼や監査証跡のために不可欠です。

修正方法

代替なしのCAPTCHA — 不適切

<!-- Fails 3.3.9: The only authentication path requires solving a visual CAPTCHA.
     No alternative is provided, and there is no object-recognition option. -->
<form method='post' action='/login'>
  <label for='username'>Username</label>
  <input type='text' id='username' name='username' autocomplete='username'>

  <label for='password'>Password</label>
  <input type='password' id='password' name='password' autocomplete='off'>

  <!-- Third-party CAPTCHA widget with no accessible alternative path -->
  <div class='g-recaptcha' data-sitekey='YOUR_SITE_KEY'></div>

  <button type='submit'>Log In</button>
</form>

CAPTCHAをパスキーとマジックリンクに置き換え — 適切

<!-- Passes 3.3.9: CAPTCHA removed entirely. Primary path uses a passkey
     (WebAuthn — no cognitive test). A magic link fallback is offered
     for devices without passkey support. Password entry allows paste
     and browser autofill. -->
<form method='post' action='/login'>
  <label for='email'>Email address</label>
  <input type='email' id='email' name='email' autocomplete='email'>

  <!-- Passkey login: no password to remember, no CAPTCHA -->
  <button type='button' id='passkey-btn'>Sign in with Passkey</button>

  <!-- Password fallback: paste and autofill explicitly enabled -->
  <label for='password'>Password (optional)</label>
  <input type='password' id='password' name='password'
         autocomplete='current-password'>
  <!-- NOTE: Do NOT add autocomplete='off' or paste-blocking JS here -->

  <button type='submit'>Log In</button>
</form>

<!-- Non-cognitive alternative: magic link -->
<p><a href='/send-magic-link'>Send me a sign-in link instead</a></p>

<script>
  // WebAuthn passkey authentication — no cognitive function test
  document.getElementById('passkey-btn').addEventListener('click', async () => {
    const credential = await navigator.credentials.get({ publicKey: publicKeyOptions });
    // submit credential to server
  });
</script>

OTPフィールドでクリップボード貼り付けをブロック — 不適切

<!-- Fails 3.3.9: The one-time code field blocks paste via JavaScript,
     forcing users to manually transcribe a time-limited code.
     This is a transcription cognitive function test with no bypass. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='off'>

<script>
  document.getElementById('otp').addEventListener('paste', function(e) {
    e.preventDefault(); // Blocks paste — FAILS 3.3.9
  });
</script>

貼り付け許可とautocompleteヒント付きのOTPフィールド — 適切

<!-- Passes 3.3.9: Paste is allowed. The autocomplete='one-time-code' attribute
     enables browsers and password managers to automatically fill the OTP,
     eliminating the transcription requirement entirely. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='one-time-code'>

<!-- No paste-blocking JavaScript. autocomplete='one-time-code' allows
     the OS (iOS, Android, desktop browsers) to suggest the OTP
     automatically from SMS or authenticator apps. -->

知識ベースのセキュリティ質問 — 不適切

<!-- Fails 3.3.9: Requiring answers to knowledge-based security questions
     is a memory-recall cognitive function test. No alternative is offered. -->
<form method='post' action='/verify-identity'>
  <p>To verify your identity, please answer your security question:</p>
  <label for='sq-answer'>What was the name of your childhood pet?</label>
  <input type='text' id='sq-answer' name='sq-answer' autocomplete='off'>
  <button type='submit'>Verify</button>
</form>

認知負荷のない代替手段による本人確認 — 適切

<!-- Passes 3.3.9: Security questions replaced with email magic link
     and government ID upload options — neither requires memory recall.
     If security questions are retained for some users, a clearly labeled
     alternative path is provided upfront. -->
<form method='post' action='/verify-identity'>
  <p>We need to verify your identity. Choose one of the following methods:</p>

  <fieldset>
    <legend>Verification method</legend>

    <label>
      <input type='radio' name='verify-method' value='magic-link' checked>
      Send a verification link to my registered email
    </label>

    <label>
      <input type='radio' name='verify-method' value='id-upload'>
      Upload a photo of a government-issued ID
    </label>
  </fieldset>

  <button type='submit'>Continue</button>
</form>

よくある間違い

• パスワードフィールドにautocomplete='off'を追加することでブラウザの自動入力を防ごうとすること。これは、ユーザーがパスワードを記憶せずに済む主要なメカニズムを無効化し、3.3.9に直接違反します。autocomplete='off'は削除し、代わりにautocomplete='current-password'またはautocomplete='new-password'を使用してください。
• 認証入力フィールドに対してJavaScriptのpasteイベントリスナーを追加し、event.preventDefault()を呼び出すことでセキュリティが向上すると考えること。実際には、これはパスワードマネージャーや支援技術をブロックし、3.3.9における書き写し要件に該当します。
• 視覚CAPTCHAに対する十分なバイパスとして音声CAPTCHAの代替を扱うこと。 音声CAPTCHAも依然として認知機能テスト（歪んだ音声文字の書き写し）であり、3.3.9を満たすものではありません。本当に認知負荷のない代替経路が必要です。
• パスキーやソーシャルログインのオプションを提供しながら、それらをCAPTCHAチャレンジの背後に置くこと。 アクセシブルな代替にアクセスするためにユーザーが認知テストを通過しなければならない場合、その代替は真に同等とはいえず、フローは3.3.9に不適合です。
• OTP入力に6つの単一文字<input>フィールドを使用すること（よくあるUIパターン）でありながら、フィールド全体にまたがる貼り付け入力をサポートしないこと。多くの実装では、貼り付けは最初のフィールドにしか反映されず、残り5つについては1文字ずつ手入力を要求しており、これは書き写しの障壁となります。
• 「ログイン状態を保持する」や永続的なセッションクッキーを、繰り返し認証できないユーザーへの唯一の配慮として扱うこと。 認証頻度を減らすことは助けになりますが、アクセシブルでない認証プロセス自体を解決するものではありません。ユーザーは少なくとも一度は認知テストを通過しなければならず、セッションは期限切れになったりクリアされたりします。
• 警告なしにタイムアウト時にクリアされる時間制限付きOTPフィールドを実装することで、ユーザーに新しいコードを要求させ、再度書き写しを試みさせること。これは、動作が遅い運動機能や認知処理速度を持つユーザーにとって認知負荷をさらに増大させます。
• 非物体コンテンツの認識を要求する画像ベースのCAPTCHAチャレンジを使用し — 抽象的なパターン、色、個人的に選択した写真のシーケンスなど — これが3.3.9を満たしていると考えること。AAA基準が許容するのは物体認識（車、自転車、信号機などの現実世界の物体）だけであり、非物体画像の認識はこのレベルでは例外になりません。
• ログインフィールドにautocomplete='new-password'を設定することでブラウザの資格情報マネージャーへのアクセスをブロックすること（本来は登録フィールドで使用すべき値）。new-password値はブラウザに対し「新しいパスワードを作成するフィールド」であることを示し、ログイン時に保存済み資格情報の自動入力を妨げます。
• 実際の支援技術を用いて認証フローをテストせず、自動スキャン結果のみに依存すること。3.3.9は手動でのみテスト可能な基準であるため、スクリーンリーダーやキーボードによる手動テストを省略するチームは、リリースのたびにこの基準の不適合を体系的に見落とすことになります。

トルコのアクセシビリティ規制との関係

トルコの大統領通達第2025/10号は、2025年6月21日付官報第32933号で公布され、トルコで事業を行う幅広い公的・民間主体に対して、包括的なウェブおよびモバイルアクセシビリティ義務を定めています。この通達はWCAG 2.2への準拠を義務付けており、2.2版の規格を明示的に参照したトルコ初の法的文書となっています。

通達の対象となる主体には、あらゆるレベルの政府機関・公的機関、eコマースプラットフォームやオンラインマーケットプレイス、銀行や金融機関、病院や医療提供者、20万以上の加入者を有する通信事業者、旅行代理店、民間輸送会社、国民教育省（MoNE）に認可された私立学校などが含まれます。これらの組織にとって、ログインポータル、患者ポータル、バンキングダッシュボード、チケッティングシステム、学生情報システムなどのデジタルサービスは、通達で定義されたアクセシビリティ要件を満たさなければなりません。

WCAG 3.3.9はAAAレベルの基準であるため、通達の下での最低限の法的義務ではありません。法的に義務付けられているベースラインは、WCAG 2.2レベルAおよびAAへの準拠に相当します。しかし、通達の趣旨と適用範囲を踏まえると、3.3.9は実務上非常に関連性が高いといえます。

第一に、WCAG 3.3.8（Accessible Authentication — Minimum）はAAレベルの要件であり、したがって対象となるすべての主体にとって法的拘束力があります。3.3.8への準拠に取り組む組織は、3.3.9への準拠が多くの場合、比較的小さな追加ステップであることに気づくでしょう — 主に、3.3.8で許容されている画像認識の例外を削除し、すべての認知テストに対して支援メカニズムだけでなく認知負荷のない代替手段を確保することです。

第二に、認知障害や運動障害の有病率が高い集団にサービスを提供する主体、特に病院、公的医療ポータル、行政サービスポータルにとって、認証に関する基準でAAA準拠を達成することは、トルコの広範な憲法上の平等原則や、トルコが批准している障害者の権利に関する国連条約（CRPD）に基づく義務と整合する、実質的な平等アクセスへのコミットメントを意味します。

第三に、トルコの銀行やフィンテック事業者は、認証に関して特に厳しい監督を受けています。銀行規制監督庁（BDDK）や金融犯罪調査委員会（MASAK）は強力な本人確認要件を課しており、組織はこれらの要件を満たすために複雑で多段階の認証フローを実装することがよくあります。パスキー、WebAuthn、マジックリンクフローを用いた3.3.9準拠の認証を実装することは、よりアクセシブルであるだけでなく、国際的な金融規制当局が推奨する最新の安全な認証ベストプラクティスとも整合しており、複数の観点からコンプライアンスに資する設計目標となります。

自らのアクセシビリティ姿勢を差別化し、将来の規制強化に備え、あるいはユーザーに対してアクセシブルかつインクルーシブなサービスを提供しようとする組織は、WCAG 3.3.9を単なる任意の強化ではなく、設計標準として扱うことが強く推奨されます。完全に認知負荷のない認証経路を実装することは、現代のブラウザAPI（WebAuthn/パスキー）や認証SDKにより、これまでになく実現しやすくなっています。コンプライアンスのコストはこれまでで最も低くなっている一方で、その利益 — あらゆるデジタルプロダクトにおける最も重大なアクセシビリティ障壁の一つを取り除くこと — は非常に大きいのです。