WCAG 2.2.5: 再認証

この規則が意味すること

WCAG 2.2.5 Re-authenticating（再認証）は、ガイドライン 2.2（十分な時間）の一部であり、レベル AAA の要件です。この達成基準は次のように述べています。「認証済みセッションが期限切れになったとき、ユーザーは再認証後にデータを失うことなく活動を継続できる。」 実務的には、ユーザーが認証されたプラットフォーム上でフォーム入力、購入手続き、メッセージ作成、その他の複数ステップのタスクの途中でセッションがタイムアウトした場合、再度ログインして、入力済みのデータがすべて保持された状態で、ちょうど中断したところから再開できなければならない、という意味です。

この達成基準は、WCAG 2.2.1（Timing Adjustable、レベル A）および 2.2.4（Interruptions、レベル AAA）と密接に関連していますが、扱うのは特定のシナリオ、すなわちセッション境界をまたぐ瞬間です。2.2.1 はユーザーに十分な時間を与えるか、セッションを延長できるようにすることを求めますが、2.2.5 は失敗ケース、つまり時間が経過した「後」に何が起こるかを扱います。この 2 つは連携して機能します。理想的には、セッションを延長すると同時に、期限切れになった場合にもデータを保持する必要があります。

この達成基準における適合（パス）には、プラットフォームがユーザー入力データ—テキスト入力、選択肢、ファイル添付、チェックボックス、ラジオボタンの選択、その他あらゆるフォームの状態—を再認証イベントをまたいで保持することが求められます。ユーザーが再ログインした後は、実行中だったアクティビティの同じ地点に戻され、データはそのままで、タスクを繰り返すことなく完了できなければなりません。

不適合（フェイル）となるのは、セッションタイムアウトによって次のいずれかが発生する場合です。ユーザーがログインページにリダイレクトされ、ログインに成功しても元いたページではなくホームページに送られる／タイムアウト前に入力したフォームデータが失われ、ユーザーがすべてを再入力しなければならない／途中まで完了していた複数ステップのウィザードの状態がリセットされる／あるいはユーザーが単にログアウトされるだけで、再認証して再開する仕組みがない、などです。

公式の WCAG 仕様では、この達成基準に対する最小セッション時間は定義されていません。タイムアウト時間が長いか短いかにかかわらず適用されます。ただし、セキュリティ上の懸念によるデータ損失についての例外は一切設けられていない点に注意してください。実装側には、ユーザーの ID に紐づけたサーバー側セッションストレージや、再認証フローをまたいで保持される暗号化されたクライアント側トークンなど、状態を安全に保持する方法を見つけることが期待されています。

なぜ重要か

データを消去してしまうセッションタイムアウトは、障害のある人にとって過度に大きな負担を生みます。多くの障害のあるユーザーは、障害のない同年代のユーザーよりもデジタルタスクの完了に大幅に長い時間を必要とし、「もっと速く入力する」ことで対応したり、恣意的なタイムアウトを「うまく回避」したりできないことが多いのです。

全盲またはロービジョンのユーザーはスクリーンリーダーを使ってフォームを操作しますが、これは視覚的なスキャンより本質的に遅くなります。長い保険金請求フォームに入力している全盲のユーザーは、フィールドごとに慎重に移動しながら 20〜30 分かけて入力しても、15 分のセッションタイムアウトが発動した瞬間に作業内容がすべて消えてしまうかもしれません。そして再び最初からやり直さなければならず、同じことが 2 回目も起こらない保証はありません。

運動障害のある人—スイッチアクセスデバイス、視線入力技術、マウススティックなどを使用している人—は、テキスト入力やフォーム操作に平均より何倍も長い時間がかかることがあります。ALS や脊髄性筋萎縮症のあるユーザーは、重要な医療紹介フォームを作成していて、1 分間に数文字しか入力できないかもしれません。彼らの作業を破壊するセッションタイムアウトは、ちょっとした不便ではなく、必須タスクの完了を完全に妨げる障壁になり得ます。

認知障害のあるユーザー（ディスレクシア、ADHD、外傷性脳損傷、認知症などを含む）は、説明文を何度も読み返したり、情報を処理するために休憩を取ったり、複数ステップのプロセスをゆっくり進めたりする必要があるかもしれません。研究では一貫して、この人たちが時間的プレッシャーやデータ損失の影響を不釣り合いに強く受けることが示されています。これらは、最初からやり直そうとする際の認知的負荷をさらに増大させます。

具体的な現実のシナリオを考えてみましょう。多発性硬化症のあるユーザーが、公的機関のウェブポータルを通じて政府の障害給付に申請しています。申請は 8 ステップあり、医療文書のアップロード、職歴の入力、自己申告文の作成が必要です。45 分かけて 6 ステップまで進んだところでセッションが期限切れとなり、入力したデータがすべて失われます。同じ文書を再度集め、全プロセスを繰り返さなければならず、最終的に申請自体を断念する可能性もあります。これは仮定の話ではなく、アクセシビリティ研究やユーザーテストで繰り返し記録されているパターンです。

障害の有無にかかわらず、セッションタイムアウトによるデータ損失はすべてのユーザーに影響し、ビジネス面でも測定可能なインパクトをもたらします。放棄されたショッピングカート、未完了の登録、失われたリードなどです。セッション状態の保持はアクセシビリティ上の必須事項であると同時に、優れた UX とコンバージョン最適化の実践でもあります。Baymard Institute によると、フォームの放棄は EC におけるカート放棄率の大きな要因であり、予期せぬデータ損失はユーザーがオンライン購入を完了しない理由として最も多く挙げられる要因の 1 つです。

関連する Axe-core のルール

WCAG 2.2.5 は手動テストのみを必要とします。この達成基準の違反を確実に検出できる自動 axe-core ルールは存在しません。以下では、自動ツールがなぜ不十分なのか、そして代わりに人間のテスターが何をしなければならないのかを説明します。

• セッション状態の保持に関する自動ルールは存在しない：axe-core や類似の自動アクセシビリティエンジンは、現在の DOM を検査し、色のコントラスト比、ARIA 属性の正しさ、代替テキストの欠如など、静的またはほぼ静的な条件を評価することで動作します。これらは時間の経過をシミュレートしたり、セッション期限切れイベントを発火させたり、再認証情報を送信したり、その後に以前入力されたデータが復元されたかどうかを検証したりすることはできません。この一連の流れは状態を持つ時間依存の挙動であり、人間（またはスクリプト化されたエンドツーエンドテスト）が観察する必要があります。
• セッションタイムアウトの検出は静的解析の範囲外：たとえ自動ツールが、meta refresh タグや JavaScript の setTimeout 呼び出しを読み取ることでページにセッションタイムアウトが実装されていると検出できたとしても、タイムアウト発動「後」にユーザーデータに何が起こるかを評価することはできません。データ保持の挙動は、ツールが解析する DOM 構造ではなく、サーバー側のセッション管理ロジックに存在します。
• 再認証フローの複雑さ：再認証の体験は複数のページ（ログインフォーム、MFA プロンプト、リダイレクト）にまたがる場合があり、状態の復元はサーバー側ロジック、Cookie、ローカルストレージ、URL パラメータなどに依存することがあります。単一ページの DOM を検査するツールでは、この複数ページ・複数システムにまたがるフローを追跡できません。
• 手動テストが不可欠な理由：有資格のテスターが、認証済みワークフローを手動で開始し、意図的にセッション期限切れを待つか発生させ、再認証プロセスを完了し、その後データの完全性を検証する必要があります。これが適合性をテストする唯一の信頼できる方法です。自動スキャンは、2.2.1 で扱われるセッション警告メカニズムの欠如など、関連する問題を指摘する出発点としては利用できますが、2.2.5 に関しては手動テストの代わりにはなりません。

テスト方法

1. 認証が必要で、フォームや複数ステップのプロセスを含むワークフローを特定する。まず、認証が必要でユーザーデータ入力を伴うサイト内の領域—チェックアウトフロー、プロフィール編集、申請フォーム、予約システム、メッセージングインターフェース、管理ダッシュボードなど—をすべて洗い出します。これらが 2.2.5 の不適合リスクが最も高い領域です。
2. セッションタイムアウト時間を特定する。サーバー設定やアプリケーション設定を確認するか、開発チームに問い合わせて、セッションがいつ期限切れになるかを把握します。あるいは、セッションを開始して自動的にログアウトされるまで待ってもかまいません。その時間を記録します。一般的なタイムアウトは 15 分から 2 時間の範囲です。
3. タスクを開始し、十分な量のデータを入力する。ログインして代表的なフォームの入力を開始します。たとえば、複数フィールドの登録フォームや購入フローなどです。テキストフィールドに入力し、選択を行い、ウィザード形式であればステップを進めます。フォームは送信しないでください。
4. セッション期限切れを発生させる。自然なタイムアウトが発生するまで待つか、開発者権限がある場合は、ブラウザの開発者ツール（Application タブ > Cookies > セッション Cookie を削除）でセッション Cookie を無効化する、あるいはサーバー側で直接セッションを期限切れにすることで、人工的にセッションを失効させます。
5. 再認証プロンプトを確認する。サイトが再認証を促すか（パス）、あるいは警告なしに単にログインページへリダイレクトするか（これは関連するユーザビリティ問題ですが、2.2.5 が焦点を当てるのは警告そのものではなくデータ保持です）を確認します。そのうえで再ログインを試みます。
6. ログイン後のデータ保持を検証する。再認証に成功した後、どこにリダイレクトされるか、そして以前入力したデータが保持されているかを確認します。ホームページに送られる、またはフォームデータが消えている場合は、2.2.5 の不適合です。
7. 支援技術を用いてテストする。NVDA と Firefox、JAWS と Chrome、VoiceOver と Safari を使って上記のテスト手順を繰り返し、再認証プロンプトがスクリーンリーダーユーザーにとってアクセシブルであること、そして復元されたページ状態が正しく読み上げられることを確認します。視覚ユーザーは復元されたデータを視覚的に認識できますが、スクリーンリーダーユーザーにはフォーカスが適切に配置され、復元されたコンテンツが読み上げ順に含まれている必要があります。
8. キーボードのみの操作でテストする。セッション期限切れの通知から、再ログイン、保持されたタスクへの復帰まで、マウスを使わずキーボードだけで一連の再認証プロセスを完了できることを確認します。
9. 延長タイムアウトをシミュレートしてテストする。可能であれば、開発環境でセッションタイムアウトを 1〜2 分に短縮し、テストサイクルを高速かつ再現性の高いものにするために、フルのユーザージャーニーテストを実行します。

修正方法

セッションタイムアウトを伴うシンプルなログインフォーム — 不適切な例

<!-- BAD: Session expires silently. On re-login, user is sent to homepage.
     All entered data in the checkout form is lost. -->
<form action='/checkout' method='POST' id='checkout-form'>
  <input type='text' name='full_name' placeholder='Full Name' />
  <input type='text' name='address' placeholder='Address' />
  <button type='submit'>Place Order</button>
</form>

<!-- Server-side: session expires after 10 minutes of inactivity.
     No state saved. POST redirect on login goes to /dashboard. -->

セッションタイムアウトを伴うシンプルなログインフォーム — 適切な例

<!-- GOOD: Before session expires, form state is saved server-side
     (or to sessionStorage as a fallback). After re-auth, the user
     is redirected back to the checkout page with data restored. -->

<!-- 1. JavaScript saves form state periodically to the server -->
<script>
  function saveFormState() {
    const formData = new FormData(document.getElementById('checkout-form'));
    const data = Object.fromEntries(formData.entries());
    // Save to server-side session keyed to authenticated user identity
    fetch('/api/save-draft', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ formId: 'checkout', data })
    });
  }
  // Auto-save every 60 seconds and on input change
  setInterval(saveFormState, 60000);
  document.getElementById('checkout-form')
    .addEventListener('input', saveFormState);
</script>

<!-- 2. On the server: when user re-authenticates,
     redirect to /checkout?restore=true
     which reloads saved draft data into the form -->
<form action='/checkout' method='POST' id='checkout-form'>
  <!-- Form fields are pre-populated from saved draft -->
  <input type='text' name='full_name' value='[restored value]'
         aria-label='Full Name' />
  <input type='text' name='address' value='[restored value]'
         aria-label='Address' />
  <button type='submit'>Place Order</button>
</form>

進捗を失うマルチステップウィザード — 不適切な例

<!-- BAD: Multi-step form uses only client-side state.
     Session expiry wipes wizard progress completely.
     Re-login sends user to step 1 with no data. -->

<div id='wizard'>
  <div class='step active' id='step-3'>
    <h2>Step 3 of 5: Employment History</h2>
    <textarea name='employment_history'>Typed content here...</textarea>
  </div>
</div>

<script>
  // State is only in JavaScript variables — lost on session expiry
  let wizardState = { step: 3, data: {} };
</script>

進捗を失うマルチステップウィザード — 適切な例

<!-- GOOD: Wizard state is persisted server-side at each step
     and linked to the user's account. On re-authentication,
     the server restores the user to their last saved step
     with all data intact. A visible confirmation is shown. -->

<div id='wizard'>
  <div class='step active' id='step-3'
       aria-live='polite' aria-label='Step 3 of 5: Employment History'>
    <p role='status'>
      Your progress has been restored from your last session.
    </p>
    <h2>Step 3 of 5: Employment History</h2>
    <!-- Data is pre-populated from server-side draft -->
    <textarea name='employment_history'
              aria-label='Describe your employment history'>
      Previously entered content restored here...
    </textarea>
    <!-- Wizard nav saves progress before moving to next step -->
    <button type='button' onclick='saveAndProceed()'>Next Step</button>
  </div>
</div>

<script>
  async function saveAndProceed() {
    await fetch('/api/wizard/save', {
      method: 'POST',
      body: JSON.stringify({ step: 3, data: collectStepData() }),
      headers: { 'Content-Type': 'application/json' }
    });
    goToStep(4);
  }
</script>

データ保持のないセッション期限切れ警告 — 不適切な例

<!-- BAD: Site shows a countdown warning but does not save data.
     If the user misses the warning (e.g., screen reader user
     focused elsewhere), they lose all their work. -->
<div id='timeout-warning' style='display:none'>
  <p>Your session will expire in 2 minutes. <a href='/extend'>Extend</a></p>
</div>

データ保持のないセッション期限切れ警告 — 適切な例

<!-- GOOD: Warning uses aria-live so screen readers announce it.
     Data is saved server-side regardless of whether the user
     extends the session — so re-auth always restores state. -->
<div id='timeout-warning'
     role='alertdialog'
     aria-live='assertive'
     aria-labelledby='warning-title'
     aria-describedby='warning-desc'
     hidden>
  <h2 id='warning-title'>Session Expiring Soon</h2>
  <p id='warning-desc'>
    Your session will expire in 2 minutes. Your work has been
    saved automatically. You can extend your session or log in
    again to continue exactly where you left off.
  </p>
  <button onclick='extendSession()'>Extend Session</button>
  <button onclick='dismissWarning()'>Dismiss</button>
</div>

よくある間違い

• 再認証後に元のページではなくホームページへリダイレクトする：最も一般的な失敗パターンです。ログイン後、アプリケーションがユーザーをセッション期限切れ時にいた URL ではなく /dashboard や / に送るため、ユーザーはタスクに戻るために手動でナビゲートしなければならず、その時点でデータはすでに失われています。
• フォーム状態を JavaScript メモリや React/Vue のコンポーネント状態のみに保存している：クライアントサイドフレームワークの状態は、セッション期限切れによるログインページへのリダイレクトで発生するページリロードをまたいで保持されません。状態はサーバー側、または戻った際に確実に復元できるストレージメカニズム（例：localStorage）に永続化する必要があります。
• 「リターン URL」だけを保存し、フォームデータを保存していない：実装によっては、ログイン後にリダイレクトする URL だけを保存し、実際のフォームフィールドの値を保存しないものがあります。ユーザーは正しいページに戻されますが、フィールドは空のままであり、これも 2.2.5 に違反します。
• sessionStorage に自動保存しているが、タブを閉じると消えてしまう：セッション期限切れによってブラウザタブが別ページに遷移（例：ログインページへのリダイレクト）すると、sessionStorage はクリアされます。ユーザーに紐づく名前空間を用いた localStorage、あるいは望ましくはサーバー側の下書き保存を使用してください。
• ファイルアップロード入力でテストしていない：ファイル入力はセキュリティ上の理由から HTML で事前に値を設定することができません。フォームにセッション期限切れ前に完了したファイルアップロードが含まれている場合、そのファイル参照は失われます。アプリケーションは、アップロードされたファイル参照をサーバー側に保存し、ユーザーにファイルがまだ添付されていることを示すことで対応しなければなりません。
• 再認証時に保存済みの下書きデータを即座に削除してしまう：実装によっては、ユーザーが復元されたデータを実際に確認し、確定したことを検証する前に、ログインした瞬間に下書きを削除してしまうものがあります。下書きは、タスクが明示的に完了またはキャンセルされるまで保持されるべきです。
• 復元されたデータをスクリーンリーダーユーザーに通知していない：再認証とリダイレクトの後、スクリーンリーダーユーザーには、データが復元され、どこから作業を再開できるかを確認する aria-live 領域やフォーカスによるアナウンスが必要です。これがないと、自分の作業が保存されていたことに気づかない可能性があります。
• AJAX ベースのセッションをページベースのセッションと異なる扱いにしている：トークンベース認証（例：JWT の期限切れ）を用いるシングルページアプリケーションでは、トークンが期限切れになってもユーザーに再認証と再開の機会を与えず、API 呼び出しが黙って失敗することがよくあります。再認証メカニズムは SPA アーキテクチャに対しても同様に堅牢でなければなりません。
• 事前のデータ保存なしに <meta http-equiv='refresh'> を使って強制ログアウトしている：タイムアウト時に発火する meta refresh は、サーバー側の状態保持なしに即座にユーザーをリダイレクトするため、データの復旧を不可能にします。セッション管理は、適切な状態永続化を伴うアプリケーション層で行う必要があります。
• セッションが短ければこの達成基準は不要だと考えている：5 分のセッションタイムアウトであっても、入力速度の遅いユーザー、説明文を読み返している認知障害のあるユーザー、あるいは介助者に呼ばれて中断したユーザーを捕まえてしまう可能性があります。タイムアウトの長さにかかわらず、再認証をまたいでデータを保持する義務は変わりません。

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

トルコの大統領通達 2025/10（2025 年 6 月 21 日付官報第 32933 号で公布）は、デジタルアクセシビリティに関する国内枠組みを定め、WCAG 2.2 を技術標準のベースラインとして参照しています。この通達は、トルコで事業を行う幅広い主体—公的機関・行政機関、EC プラットフォーム、銀行・金融サービス提供者、病院・民間医療機関、20 万人以上の加入者を持つ通信会社、旅行代理店、民間輸送会社、国民教育省（MoNE）に認可された民間教育機関—に適合を義務付けています。

WCAG 2.2.5 Re-authenticating はレベル AAA の達成基準であり、通達が対象とするレベル A および AA の適合（法的に義務付けられた最低要件）の中には含まれていません。しかし、アクセシビリティにおけるリーダーシップを示したい組織、多様なユーザー層（障害のある人を含む）にサービスを提供したい組織、あるいはデジタルサービスのベストプラクティスを体現する存在として位置づけられたい組織は、特に 2.2.5 のように実務的なインパクトが大きいレベル AAA の達成基準を、追求する価値のある目標として扱うべきです。

対象となる主体の中には、特に 2.2.5 を実装する強い理由を持つカテゴリーがあります。銀行や金融プラットフォームは、ローン申請、口座開設、投資商品などのために長いフォーム入力をユーザーに求めることが多く、セキュリティ上の理由から短いセッションタイムアウトを設定しているため、データ保持義務との間に直接的な緊張関係が生じます。病院やヘルスケアポータルは、予約手続きや健康質問票の入力など、ケアの継続性に実際の影響を及ぼし得る重要なタスクの最中に患者をデータ損失にさらします。電子政府サービス（納税申告、許認可申請、給付申請など）を運営する公的機関は、複雑な政府フォームの入力に長い時間を必要とする障害のある市民にサービスを提供しています。

レベル AAA への適合が法的に要求されていない場合でも、トルコの組織は、規制当局、市民社会組織、障害者権利擁護団体が、デジタルアクセシビリティ実装の質と完全性をますます厳しく精査していることを認識しておくべきです。2.2.5 のようなレベル AAA 達成基準への適合を文書化することは、組織のアクセシビリティ声明を強化し、訴訟リスクを低減し、最低限のチェックボックスを超えたインクルーシブデザインへの真のコミットメントを示すことにつながります。特にトルコと並行して EU 市場でも事業を行う国際的な組織にとっては、レベル AAA の達成基準が European Accessibility Act（EAA）および関連する各国実装の要件と交差する可能性もあります。