WCAG 3.3.8: アクセシブルな認証（最小限）

WCAG 3.3.8 は、代替手段や支援が利用可能でない限り、パスワードの記憶、パズルの解決、文字の書き写しといった認知機能テストに認証プロセスが依存してはならないと定めています。これは、認知障害のあるユーザーがデジタルサービスから締め出されることを防ぐためのものです。

この規定の意味

WCAG 3.3.8「Accessible Authentication (Minimum)」は、WCAG 2.2 で導入されたレベルAAの達成基準です。ここでは、認知機能テスト（ユーザーに情報を記憶させる、操作させる、または書き写させることを必要とするタスクと定義される）が、認証ステップを完了するための唯一の手段であってはならないと定めています。ただし、次のいずれかの条件を満たす場合は例外です。

代替手段: 認知機能テストに依存しない別の認証経路が利用できる（例: メールで送信されるマジックリンク、生体認証ログイン、パスキーなど）。
支援メカニズム: ユーザーエージェントまたはサードパーティツールが、ユーザーに代わってステップを完了することが許可されている（例: パスワードマネージャーによる資格情報の自動入力、ワンタイムコードのコピー＆ペーストなど）。
物体認識の例外: 認知機能テストが、画像内の物体を識別することを伴う（例: 信号機を含むすべての画像を選択する）—この種のテストは Minimum（AA）レベルでは許可されています。
個人コンテンツの例外: テストが、ユーザー自身が提供したコンテンツに依拠している（例: 以前にアップロードした写真をグリッドから選択する）。

実務的には、ユーザー名とパスワードのみを要求するログインフォームであっても、ブラウザの自動入力やパスワードマネージャーが機能するようになっていれば（つまり、フィールドが標準的な <input type='password'> を使用し、ペーストをブロックしていない場合）、この達成基準に準拠します。代替の認証手段が一切ない状態で、歪んだテキストを書き写すことを要求する CAPTCHA は明確な不適合です。カテゴリーに一致する画像を選択させる CAPTCHA（物体認識）は AA レベルでは許可されていますが、AAA（3.3.9）ではより厳しく扱われます。

この達成基準は、認証プロセスのすべてのステップに適用されます。初回ログイン、ステップアップ認証、多要素認証、アカウント復旧、セッション再認証などです。また、主たるサインイン画面に限らず、機能へのアクセスを保護するあらゆるプロセスにも適用されます。

技術的な重要ポイントとして、開発者は認証フィールドに autocomplete='off' を使用してはならず、JavaScript のイベントハンドラでペーストを無効化してはならず、支援技術やブラウザの自動入力が正しく動作するための標準的な入力セマンティクスを壊してはなりません。

なぜ重要か

認証は、人々が日常的に利用するほぼすべてのデジタルサービス—銀行、医療ポータル、行政サービス、eコマース、コミュニケーションプラットフォーム—への入り口です。この入り口が認知的なハードルを課すと、人口の相当な割合を体系的に排除することになります。

認知障害は幅広いスペクトラムを含みます。ディスレクシア、ディスカルキュリア、注意欠如障害、脳損傷、認知症、知的障害、不安障害などです。世界保健機関は、世界人口のおよそ6人に1人が何らかの重大な障害を経験していると推計しており、その中でも認知および神経学的な状態は最大のカテゴリーの一つです。これらのユーザーにとって、歪んだ文字列を正確に書き写す、時間制限のある視覚パズルを解く、認証アプリとログインフォームの間を行き来する、といったタスクは、本当に不可能であったり、極度に消耗を伴うものになり得ます。

具体的なシナリオを考えてみましょう。ディスレクシアのある人が、検査結果を確認するために健康保険ポータルへログインしようとします。サイトは音声代替も回避手段もないテキスト CAPTCHA を提示します。歪んだ文字はこのユーザーには判別できず、入力フィールドはペーストをブロックしています。複数回失敗した後、アカウントはロックされます。ユーザーは時間的制約のある医療情報にアクセスできません。これは仮想的なレアケースではなく、何百万人もの人々にとって日常的に起きていることです。

スイッチアクセスや視線入力デバイスに依存する運動障害のあるユーザーも影響を受けます。別のデバイスに表示された複雑なワンタイムパスコードを再入力したり、画像タイルを特定の順序にドラッグしたりすることは、これらの入力手段では物理的に不可能な場合があります。コピー＆ペーストやパスキー認証を許可することで、このバリアは完全に解消されます。

高齢者も重要なグループです。加齢に伴う認知機能の低下は記憶力や処理速度に影響し、複雑な CAPTCHA や複数ステップの記憶タスクを不釣り合いに困難なものにします。トルコおよび世界全体で高齢化が進む中、アクセシブルな認証に対するビジネス上・規制上の必要性は年々高まっています。

ユーザビリティとコンバージョンの観点からも、認証フローの摩擦は離脱率を直接的に高めます。テキスト CAPTCHA をリスクベース認証やパスキーに置き換えた eコマースプラットフォームは、ログイン完了率の向上と、アカウントロックに関連するサポートコストの削減を一貫して報告しています。

テスト方法

自動スキャン（axe DevTools / Lighthouse）: 各認証ページ（ログイン、登録、アカウント復旧、MFA）で axe DevTools を実行します。ユーザー名とパスワードフィールドに対する autocomplete-valid 違反を確認します。Lighthouse では、アクセシビリティ監査でフォーム関連の問題を確認します。3.3.8 の不適合を明確に示す自動ルールは存在しない点に注意してください—自動結果はあくまで出発点に過ぎません。
すべての認知機能テストを特定する: 認証フローのすべてのステップを手動で洗い出します。現在の画面に表示されていない情報を思い出す、文字を写し取る、パズルを解く、計算を行う、といったことをユーザーに要求するステップをすべて記録します。それぞれのステップについて、準拠した代替手段（物体認識、個人コンテンツ、代替ログイン方法、支援メカニズム）があるかどうかを確認します。
ペースト機能のテスト: すべての認証入力（ユーザー名、パスワード、OTP、復旧コード）で、キーボードショートカット（Windows/Linux では Ctrl+V、macOS では Cmd+V）を使ってテキストをペーストしてみます。ペーストした内容がフィールドに表示されることを確認します。右クリックのコンテキストメニューでも同様に試します。ペーストがブロックされている場合、認知機能テストを伴わない代替手段が存在しない限り不適合です。
パスワードマネージャーによる自動入力のテスト: パスワードマネージャー（ブラウザ標準または拡張機能）を備えたブラウザを使用し、登録時に資格情報を保存してからログインページに戻ります。パスワードマネージャーがフィールドを検出し、自動入力できることを確認します。Firefox + NVDA、Safari + VoiceOver（macOS/iOS）、Chrome + JAWS でテストし、主要な支援技術＋ブラウザの組み合わせをカバーします。フィールドが非標準のマークアップを使用している、または JavaScript が自動入力された値をクリアしている場合は不適合です。
NVDA + Firefox — スクリーンリーダーでの確認: キーボードと NVDA のみを使用してログインフォームを操作します。すべてのフィールドに到達できること、フィールドラベルが正しく読み上げられること、CAPTCHA ウィジェットがある場合はアクセシブルな代替手段があることを確認します。CAPTCHA が純粋に視覚的で、音声オプションも代替ログインパスもない場合は不適合として記録します。
VoiceOver + Safari（iOS）: モバイルデバイスで、サイトが生体認証ログインを提供している場合は Face ID または Touch ID を使ってログインを試みます。スワイプ操作で生体認証オプションに到達できること、VoiceOver がそれを正しく読み上げることを確認します。これは、認知機能テストを伴わない代替手段が名目上存在するだけでなく、実際に操作可能であることを検証するものです。
認知ステップにおける時間制限の確認: CAPTCHA や OTP 入力に時間制限がある場合、ユーザーがそれを延長または無効化できるかどうか（2.2.1 に関連）を確認し、別途、その時間制限付きステップが代替手段のない認知機能テストに該当していないかを記録します。

修正方法

代替のないテキスト CAPTCHA — 不適切な例

<!-- Fails 3.3.8: only authentication method is transcribing distorted text;
     no alternative login path is offered, and paste is disabled -->
<form action='/login' method='post'>
  <label for='user'>Username</label>
  <input type='text' id='user' name='username'>

  <label for='pass'>Password</label>
  <input type='password' id='pass' name='password'
         autocomplete='off'
         onpaste='return false;'>

  <img src='/captcha-image.png' alt=''>
  <label for='captcha'>Type the characters above</label>
  <input type='text' id='captcha' name='captcha'
         autocomplete='off'
         onpaste='return false;'>

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

代替のないテキスト CAPTCHA — 適切な例

<!-- Passes 3.3.8: text CAPTCHA is replaced with a passkey / magic-link option;
     password field supports autofill and paste so password managers can assist -->
<form action='/login' method='post'>
  <label for='user'>Username or email</label>
  <input type='text' id='user' name='username'
         autocomplete='username'>

  <label for='pass'>Password</label>
  <input type='password' id='pass' name='password'
         autocomplete='current-password'>

  <!-- No CAPTCHA; bot protection handled server-side via risk-based signals -->
  <button type='submit'>Log in</button>
</form>

<!-- Cognitive-function-free alternative always visible -->
<p><a href='/magic-link'>Send me a sign-in link by email instead</a></p>
<p><a href='/passkey-login'>Sign in with a passkey or biometrics</a></p>

ペーストをブロックする OTP フィールド — 不適切な例

<!-- Fails 3.3.8: user must manually type a 6-digit OTP;
     paste is suppressed, forcing a transcription task -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp'
       inputmode='numeric'
       maxlength='6'
       autocomplete='off'
       onpaste='event.preventDefault();'
       ondrop='event.preventDefault();'>

ペーストをブロックする OTP フィールド — 適切な例

<!-- Passes 3.3.8: paste and autofill are permitted;
     autocomplete='one-time-code' enables OS-level SMS/OTP autofill on mobile -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp'
       inputmode='numeric'
       maxlength='6'
       autocomplete='one-time-code'>
<!-- Remove all paste/drop prevention handlers.
     Risk of credential stuffing is managed server-side, not by blocking paste. -->

フォールバックのない画像選択 CAPTCHA（AAA の懸念、AA では適合）— AA では適切な例

<!-- Passes 3.3.8 (AA): object recognition CAPTCHAs are explicitly
     exempted at the Minimum level. Selecting images of bicycles
     qualifies as object recognition, not character transcription.
     Note: this would fail 3.3.9 (AAA) — provide an alternative for full conformance. -->
<fieldset>
  <legend>Select all images that contain a bicycle</legend>
  <ul role='list'>
    <li>
      <input type='checkbox' id='img1' name='captcha' value='1'>
      <label for='img1'>
        <img src='/grid/img1.jpg' alt='A city street with parked vehicles'>
      </label>
    </li>
    <!-- additional grid items -->
  </ul>
</fieldset>

よくある間違い

パスワードフィールドに autocomplete='off' を設定する: これはパスワードマネージャーの自動入力を無効にし、標準的なパスワード認証を準拠させる支援メカニズムを取り除いてしまいます。代わりに autocomplete='current-password' を使用し、資格情報の保存はブラウザに任せてください。
onpaste='return false;' や addEventListener('paste', e => e.preventDefault()) でペーストをブロックする: これにより、ユーザーは資格情報を手入力せざるを得なくなり、アクセシブルでない書き写しタスクが発生します。認証入力からはすべてのペースト防止ハンドラを削除してください。
キーボード操作できないパスキーオプションを提供する: 生体認証の代替手段は、キーボードと支援技術で到達・操作できる場合にのみ 3.3.8 を満たします。ホバーメニューの裏に隠されたパスキーボタンや、フォーカス不可能な <div> として実装されたものは、準拠した代替手段とは見なされません。
ボット対策としてテキスト CAPTCHA のみを使用する: デバイスフィンガープリント、タイピングの癖、IP レピュテーションなどを分析するリスクベースのサーバーサイドボット検出に切り替えることで、セキュリティを損なうことなく認知機能テスト自体を排除できます。クライアントサイドの CAPTCHA のみに依存することは、アクセシビリティ上の不適合であると同時に、セキュリティ上も好ましくありません。
OTP を複数の1文字入力に分割し、フィールド間のペーストをブロックする: 一部の実装では、OTP 入力に 6 つの別々の <input maxlength='1'> フィールドを使用し、JavaScript でフォーカスを自動移動させます。このパターンは、パスワードマネージャーからのペーストをしばしば壊し、3.3.8 に違反します。最初のフィールドにコード全体をペーストし、文字を正しく分配する実装になっている場合を除きます。
アカウント復旧フローにのみ画像ベース CAPTCHA を要求する: チームはメインのログインページにはアクセシブルなログイン代替手段を追加しながら、ステップアップ認証、パスワードリセット、アカウントロック解除フローを見落としがちです。これらはそれぞれ独立した認証ステップであり、3.3.8 に個別に準拠していなければなりません。
音声 CAPTCHA をテキスト CAPTCHA の完全な代替とみなす: 音声代替は視覚障害のあるユーザーには有効ですが、認知障害のあるユーザーや騒がしい環境にいるユーザーには役立ちません。音声 CAPTCHA 自体も書き写しを要求します。正しい解決策は CAPTCHA を排除するか、認知機能テストを一切伴わない経路を提供することです。
パスワードマネージャーの検出を妨げる動的な入力フィールド ID を生成する: ユーザー名やパスワードフィールドの id 属性をページ読み込みごとにランダム化する（誤ったボット対策）と、パスワードマネージャーはフィールドを安定して特定できません。これは実質的に自動入力を無効化し、準拠した支援メカニズムを取り除くことになります。
サードパーティ CAPTCHA ウィジェットが自動的に準拠していると想定する: 一般的な CAPTCHA サービスはアクセシブルなバリアントを提供している場合がありますが、それらはデフォルトでは有効になっていません。開発者はアクセシブル版を明示的に設定し、そのうえで単に別種のアクセシブルでないテストを追加していないか、基準の要件を満たしているかを検証する必要があります。
フォーカス時に JavaScript で自動入力された値をクリアする: 一部のフォームは、プレースホルダーテキストを表示する、または再入力を促す目的で、フィールドがフォーカスを受けた際に内容をクリアします。この挙動がパスワードマネージャーの自動入力値を消してしまうと、手入力を強制することになり、3.3.8 に不適合となります。

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

トルコの大統領通達 2025/10は、2025年6月21日付官報第32933号で公布され、WCAG 2.2 に整合したウェブおよびモバイルのアクセシビリティ義務を定めています。この通達は、対象組織に対し、デジタル製品およびサービス全般でレベルAAの適合を満たすことを求めています。WCAG 2.2 におけるレベルAAの達成基準である WCAG 3.3.8 は、この通達が導入した義務的な適合要件の範囲に直接含まれます。

この通達は、民間・公共の幅広い組織を対象としています。公共機関および政府機関は、AA レベルの完全な適合を達成しなければなりません。民間部門では、この通達は eコマースプラットフォーム、銀行および金融機関、病院および民間医療提供者、20万件以上の加入者を持つ通信事業者、旅行代理店、民間輸送会社、国民教育省（MoNE）に認可された私立学校に適用されます。これらの組織にとって、サポートされていない CAPTCHA を用いたログインページやペーストをブロックする OTP フィールドなど、アクセシブルでない認証フローは、直接的な規制リスクを生み出します。

アクセシビリティロゴ（Erişilebilirlik Logosu）は、家族・社会サービス省が発行する、トルコにおけるデジタルアクセシビリティ適合の公式認証マークです。このロゴを取得するには、3.3.8 を含むレベルAAの適合を実証する必要があります。eコマース事業者、銀行、その他トラフィックの多いデジタルサービス提供者にとって、このロゴは公共の信頼のシグナルとなり、調達や入札要件で参照される場合もあります。認知機能テストに依存する認証フローは、認証取得を妨げ、苦情や執行措置の対象となる可能性があります。

実務的なコンプライアンスの観点から、トルコの組織は、アクセシビリティロゴの審査を申請する前に、ログイン、登録、MFA、パスワードリセット、アカウントロック解除など、すべての認証タッチポイントを 3.3.8 に照らして監査すべきです。テキスト CAPTCHA をリスクベースのサーバーサイド制御に置き換えること、すべての資格情報フィールドで autocomplete を有効にすること、パスキーやマジックリンクの代替手段を提供することは、最も効果の高い是正措置です。これらの変更は、規制要件を満たすと同時に、デジタルサービスを利用するトルコ国内推計850万人の障害のある人々にとっての認証体験を改善します。

出典と参考資料

AWCAG 1.1.1: 非テキストコンテンツ AWCAG 1.2.1: 音声のみおよび映像のみ（事前録画）AWCAG 1.2.2: キャプション（事前録画）