WCAG 2.2.6: タイムアウト

このルールの意味

WCAG 2.2.6 Timeouts（レベルAAA）は、ユーザーの非アクティブ状態が原因でデータが失われる可能性がある場合、その非アクティブの許容時間についてユーザーに警告することを求めています。ただし、データがユーザーの非アクティブ状態から20時間を超えて保持される場合は除きます。実務的には、もしあなたのWebアプリケーションやサービスが、一定時間ユーザーが操作しなかったことにより、フォーム入力内容、ショッピングカート、進行中のトランザクションなどのユーザーデータを失う可能性があるなら、そのデータが失われるまでにユーザーにどれくらいの時間があるのかを正確に知らせなければなりません。

この達成基準は、タイムアウトによってデータが失われるあらゆる状況に適用されます。よくある例としては、銀行や政府ポータルでのセッション期限切れによりフォームデータが消去されるケース、一定時間の非アクティブ後に空になるショッピングカート、セッションクッキーの有効期限切れでリセットされるマルチステップウィザードやフォーム、部分的な回答が破棄されるオンラインテストや予約システムなどがあります。重要なトリガーは、「非アクティブ状態」と「データ損失という結果」の組み合わせであり、タスク完了に対する固定時間制限（2.2.1で扱われる）そのものではありません。

適合とみなされる条件: ページは、セッション開始時、またはユーザーがデータ入力を始める前に、データ損失を引き起こす非アクティブの具体的なタイムアウト時間を明確に知らせていれば、2.2.6に適合します。あるいは、ユーザーがどれだけ長く非アクティブであってもデータ損失が発生しない場合（たとえば、サーバーがすべてのフォームデータを20時間超、あるいは無期限に保持する場合）も適合となります。セッションがすでに期限切れになった後にのみ警告を表示することは、この達成基準を満たしません。

不適合とみなされる条件: ページが、非アクティブ状態の後にユーザーデータを黙って失わせ、そのリスクについてユーザーに一度も知らせない場合、不適合となります。また、警告が存在していても、データ損失が発生する瞬間（すでに手遅れのタイミング）にのみ提示される場合や、「セッションが期限切れになる可能性があります」のように、タイムアウトを引き起こす非アクティブ時間の実際の長さを明示せず曖昧な表現にとどまる場合も不適合です。

公式の例外: この達成基準は、データが20時間を超える非アクティブ状態でも保持される状況を明示的に免除しています。20時間という閾値は、ある日にタスクを開始し、翌日に再開するユーザーを想定して設定されています。もしシステムが、ユーザーの操作を必要とせずに、入力されたすべてのデータをサーバー側で少なくとも20時間確実に保存するのであれば、警告を表示する義務はありません。さらに、この達成基準は、セキュリティ上不可欠なタイムアウトには適用されません。たとえば、ユーザーの操作に関わらず、一定時間後にセッションを終了させることを法律や規制が厳格に求めている場合などです。このようなケースでは、この達成基準は依然として開示を推奨しますが、法的制約があることを認めています。

なぜ重要か

十分な警告のないタイムアウトは、認知障害、運動障害のある人、そして全盲やロービジョンの人々に不釣り合いな影響を与えます。ディスレクシア、ADHD、外傷性脳損傷などの認知障害があるユーザーは、フォームを送信する前に、説明文を読む、文章を作成する、情報を確認するのに、はるかに多くの時間を必要とする場合があります。作業中にもかかわらずセッションが黙ってタイムアウトすると、それまでの努力をすべて失い、最初からやり直さなければならなくなります。これは非常に落胆させる体験であり、タスク自体を完全に放棄してしまう原因になり得ます。

スイッチアクセス、視線入力装置、その他の代替入力手段に依存する運動障害のある人は、マウスユーザーよりもはるかに遅いペースでインターフェースとやり取りします。長い保険金請求フォームや複数ページにわたる行政手続きの申請書を完了するには、デフォルトのセッションタイムアウトが想定している時間よりも、何倍も長い時間がかかるかもしれません。カウントダウンを知らなければ、進捗を保存したり延長を求めたりといった行動を、データが消える前に取る機会がありません。

スクリーンリーダーユーザーも、複合的な困難に直面します。複雑なフォームを操作するには、各フィールドを読み上げ、キーボードで確認する必要があるため、より多くの時間がかかります。ユーザーが長いフォームを着実に進めている最中にセッションが期限切れになることは、単なる不便ではなく、数時間分の努力が失われ、重要なサービスへのアクセスに対する重大な障壁となり得ます。

次のような現実のシナリオを考えてみてください。多発性硬化症のあるユーザーが、政府ポータルを通じて障害給付を申請しています。フォームは12セクションからなり、証拠書類のアップロードが必要です。セッションは15分の非アクティブ後に期限切れになりますが、ユーザーはセクション7の途中で、別の部屋にある書類を取りに行くために中断しました。戻ってくると、すべてのデータが消去されており、何の事前警告もなく最初からやり直さなければなりません。2.2.6の下では、このポータルは、非アクティブ状態が15分を超えるとデータが失われることを、最初にユーザーへ知らせる必要があります。そうすることで、ユーザーはそれに合わせて計画を立てることができます。

アクセシビリティの観点を超えても、タイムアウトの挙動を事前に開示することは、すべてのユーザーのユーザーエクスペリエンスを向上させ、チェックアウト、登録、申請フォームなど価値の高いコンバージョンフローにおける離脱率を下げます。また、ユーザーが自分のデータがなぜ消えたのか疑問に思わずに済むため、信頼の構築にもつながります。

関連する axe-core のルール

WCAG 2.2.6は手動テストを必要とします。この違反を検出できる自動のaxe-coreルールは存在せず、その理由を理解することはテスターと開発者の双方にとって重要です。

• 手動テストが必要 — セッションタイムアウトの開示: axe-coreのような自動ツールは、DOMをスキャンして特定の要素、属性、テキストパターンの有無を確認できますが、Webアプリケーションが非アクティブ状態の後にユーザーデータを失うかどうかを判断することはできません。タイムアウトの挙動は通常、サーバー側のセッション設定（例: PHP や Node.js のセッションTTL）によって制御されており、開示が存在する場合でも、それはオンボーディングテキスト、モーダルダイアログ、ヘルプページ、あるいは利用規約のセクションに現れるかもしれません。静的なDOM解析だけでは、ある情報テキストと実際のサーバー側タイムアウト挙動を確実に関連付けることはできません。ツールは、「セキュリティ保護のため、セッションは15分後に期限切れになります」といった文が正確かどうか、そのページのデータに適用されるかどうか、ユーザーが行動可能なタイミング（ユーザージャーニーの十分早い段階）で提示されているかどうかを知ることができません。アプリケーションと対話し、時間経過に伴う挙動を観察し、開示の内容とタイミングの妥当性を評価できる人間のテスターだけが、適合状況を判断できます。
• 手動テストが必要 — データ保持の検証: axe-coreは20時間の例外も検証できません。データが実際にサーバー側で20時間を超えて保存されているかどうか、したがって開示がそもそも必要かどうかは、ブラウザベースのスキャンツールからは見えないバックエンドロジックに完全に依存しています。テスターは、サーバー設定を確認するか、開発者と話すか、あるいは部分的に入力したフォームを長時間放置し、データが保持されているかどうかを観察することで、経験的にテストする必要があります。

テスト方法

1. 自動プレスキャン: フォーム、チェックアウトフロー、その他のデータ入力インターフェースを含むページに対して、axe DevTools や Lighthouse を実行します。どちらのツールも2.2.6の違反を直接フラグ付けすることはありませんが、このステップを使って、警告メカニズムの一部となり得るタイムアウト関連のARIAライブリージョンやダイアログコンポーネントを特定し、それ自体がアクセシブルである（適切なロール、ラベル、フォーカス管理がある）ことを確認します。
2. タイムアウト挙動の特定: 開発チームと話すか、サーバー側の設定を確認して、セッションの非アクティブタイムアウト時間を特定します。よくある場所としては、Webサーバーの設定ファイル、アプリケーションのセッションミドルウェア設定、認証プロバイダーのドキュメントなどがあります。正確な時間を分単位で記録します。
3. 事前開示の確認: ページを新規に読み込み、データ入力が始まる前にユーザーに提示されるすべてのコンテンツを読みます。ページ本文、導入段落、バナー、モーダルなどに、非アクティブの具体的なタイムアウト時間を明示し、その時間非アクティブでいるとデータが失われることを述べている明確な記述があるか探します。開示は、「15分」のように時間を明示的に示さなければならず、「短時間」などの曖昧な表現ではいけません。
4. スクリーンリーダーでのテスト: NVDA＋Firefox、VoiceOver＋Safari、または JAWS＋Chrome を使用して、ページの最初からナビゲートします。タイムアウトの開示が、ユーザーに探させることなくスクリーンリーダーによって到達され、読み上げられることを確認します。開示が視覚的に目立つバナーにある場合は、読み上げ順序において最初のフォームフィールドより前に配置されていることを確認します。
5. 非アクティブ状態のシミュレーション: フォームの入力を開始します。その後、タイムアウト時間より少し短い時間だけページとのやり取りをやめ、何が起こるか観察します。次に、タイムアウト時間を過ぎるまで待って同じことを繰り返します。データが失われるかどうか、データ損失が起こる前に警告が表示されるかどうか、その警告がセッション開始前に伝えられていたかどうかを記録します。
6. 20時間の例外のテスト: チームが「データは20時間を超えて保持される」と主張する場合は、フォームを部分的に入力し、少なくとも20時間待ってからページに戻り、データがまだ存在することを確認することで、これを経験的に検証します。あるいは、開発チームとともにサーバー側のセッションストア設定を確認します。
7. キーボードとフォーカスのテスト: タイムアウト警告のダイアログや通知が表示される場合、キーボードのみのナビゲーションを使って、それが自動的にフォーカスを受け取ること、その内容が完全に読み取れること、そしてマウスを使わずにダイアログを閉じたり（セッション延長などの）アクションを実行できることを確認します。

修正方法

セッションでデータが黙って失われる — 不適切な例

<!-- A multi-step form with a 10-minute server session timeout.
     No warning is displayed anywhere on the page.
     After 10 minutes of inactivity, the session is destroyed
     and all entered data is lost. -->
<form action='/submit-application' method='post'>
  <h1>Benefit Application</h1>
  <label for='full-name'>Full Name</label>
  <input type='text' id='full-name' name='full-name'>
  <!-- ... many more fields ... -->
  <button type='submit'>Submit Application</button>
</form>

セッションでデータが黙って失われる — 適切な例

<!-- The timeout duration is disclosed clearly before any form fields.
     The disclosure is in the natural reading order so screen readers
     encounter it before the first input. -->
<main>
  <h1>Benefit Application</h1>
  <div role='note' aria-label='Session timeout notice'>
    <p>
      <strong>Important:</strong> This form will time out after
      <strong>10 minutes of inactivity</strong>, and any information
      you have entered will be lost. Please have all required documents
      ready before you begin, or save your progress regularly.
    </p>
  </div>
  <form action='/submit-application' method='post'>
    <label for='full-name'>Full Name</label>
    <input type='text' id='full-name' name='full-name'>
    <!-- ... many more fields ... -->
    <button type='submit'>Submit Application</button>
  </form>
</main>

チェックアウトセッションの曖昧な警告 — 不適切な例

<!-- The warning exists but is vague — it does not state the actual
     timeout duration, making it impossible for users to plan. -->
<p class='notice'>Your session may expire due to inactivity.</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

チェックアウトセッションの曖昧な警告 — 適切な例

<!-- The warning now states the exact duration so users can
     make an informed decision about when to begin the checkout. -->
<p class='notice'>
  For your security, your checkout session will expire after
  <strong>20 minutes of inactivity</strong>. Any payment information
  entered will need to be re-entered if the session expires.
</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

データがサーバー側で20時間超保持される — 適切な例（例外が適用）

<!-- When all form data is saved to the server continuously
     and preserved for at least 20 hours, no timeout warning
     is required by 2.2.6. This is the ideal UX pattern:
     autosave is indicated to the user for transparency. -->
<main>
  <h1>Job Application</h1>
  <p>
    Your progress is automatically saved as you type.
    You can leave and return to this form at any time within
    <strong>30 days</strong> and your answers will be preserved.
  </p>
  <form action='/apply' method='post'>
    <label for='cover-letter'>Cover Letter</label>
    <textarea id='cover-letter' name='cover-letter'></textarea>
    <p aria-live='polite' id='autosave-status'>Draft saved.</p>
    <button type='submit'>Submit Application</button>
  </form>
</main>

よくある間違い

• タイムアウト警告をブラウザコンソール内や、エンドユーザーから見えないサーバーログエントリ内にのみ表示すること — 警告はユーザーインターフェース上に、データ損失が起こる前にユーザーが目にする場所で提示されなければなりません。
• 開示をフッター、プライバシーポリシー、利用規約ページなど、ユーザーがデータ入力を始める前に読む可能性が低い場所に置き、フォームそのもの、またはその直前ではなくしてしまうこと。
• セッションの期限切れが近いことを警告するモーダルダイアログを使用しながら、キーボードフォーカスをそのダイアログに移動させないこと — キーボードユーザーやスクリーンリーダーユーザーは、警告が表示されたことに気づかないかもしれません。
• 「セッションは30分続きます」のようにセッションの長さを述べるだけで、「15分間操作がないとデータが失われます」のような非アクティブタイムアウトを示さないこと — これらは異なる概念であり、2.2.6で対象となるのは非アクティブによって引き起こされるデータ損失のみです。
• 視覚ユーザー向けのタイムアウト警告モーダルが存在するからといって達成基準を満たしていると想定してしまうこと — モーダルがキーボードで操作できず、アクセシブルネームを欠き、ARIAライブリージョンやフォーカス管理によって通知されない場合、スクリーンリーダーユーザーは警告を受け取れません。
• サーバー側のセッションタイムアウトを25時間に設定し、ブラウザ側やアプリケーションレベルの状態（例: ReduxストアやlocalStorage）がそれより早くクリアされるかどうかを確認しないまま、開示は不要だと結論づけてしまうこと — 実効的なタイムアウトは、どのメカニズムが最初にデータを失わせるかによって決まります。
• ホバーでのみ表示されるツールチップ内にタイムアウト時間を開示すること — キーボードナビゲーションやタッチデバイスに依存するユーザーは、その開示に一度も触れない可能性があります。
• データ損失がすでに発生した後に表示される「session expired」といった汎用的なCMSやフレームワークの警告に頼り、ユーザーがデータ入力を始める前に積極的に情報提供することを怠ること。
• フォームをバックグラウンドタブで開くユーザーを考慮しないこと。セッションタイマーがタブの非アクティブ中も進行する場合、ユーザーがフォームと一度もやり取りする機会を得る前にデータが失われる可能性があります。これは、バックグラウンドタブを積極的にサスペンドするモバイルブラウザでは特に問題になります。
• デスクトップ版では警告を表示している一方で、モバイル版やプログレッシブウェブアプリ（PWA）コンテキストでは警告を省略し、多くのユーザーに対して2.2.6に不適合な不整合な体験を生じさせること。

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

トルコの大統領通達 2025/10 は、2025年6月21日付官報第32933号で公布され、トルコで事業を行う幅広い公的・民間主体に対して拘束力のあるWebアクセシビリティ義務を定めています。この通達は、技術標準としてWCAG 2.2への準拠を義務付けており、対象組織に対して少なくともレベルAAの適合を求めています。WCAG 2.2.6 Timeouts はレベルAAAの達成基準であるため、通達が定めるベースライン要件として直接義務付けられているわけではありません。しかし、この通達の対象範囲と趣旨を踏まえると、対象組織が2.2.6のような達成基準についてAAA適合を目指す実務的な理由は非常に強いと言えます。

大統領通達 2025/10 の対象には、公的機関・行政機関、eコマースプラットフォーム、銀行・金融機関、病院・医療提供者、20万件超の加入者を持つ通信事業者、旅行代理店、民間輸送会社、そして国民教育省（MoNE）に認可された私立学校が含まれます。これらのセクターの多くは、2.2.6が保護しようとしているまさにその種のデータ入力ワークフロー — ローン申請、患者受付フォーム、チケット予約システム、入学申請、政府給付の申請など — を伴うオンラインポータルを運営しています。

特に銀行やeコマースプラットフォームにとって、セッションタイムアウトは日常的なセキュリティ対策であり、セキュリティ要件とアクセシビリティ義務の相互作用は非常に関連性が高いテーマです。銀行が、一定時間のアイドル状態後にセッションを終了させる規制上の義務を負っている場合でも、タイムアウト時間を事前に開示することでWCAG 2.2.6を実装することは、そのセキュリティ要件と矛盾しません。むしろそれを補完するものです。ユーザーは制約を認識できる一方で、銀行はセッションセキュリティの姿勢を弱める必要がありません。

通達の対象となる医療提供者や病院は、患者の病歴フォーム、事前認可の申請、予約システムなど、想像し得る中でも最も重要度の高いデータ入力タスクを扱っています。これらの文脈で、認知障害や運動障害のある患者がフォーム入力の途中でデータを失うと、単なるフラストレーションにとどまらず、受診の遅れにつながる可能性があります。こうした環境で2.2.6を実装することは、通達の根底にあるインクルーシブなサービス提供の使命を直接的に体現するものです。

レベルAAAは法的には要求されていないものの、2.2.6のような達成基準についてAAAを達成すること — つまり、実装コストが比較的低い（フォームに正確な開示文を1つ追加するだけでよい）一方で、脆弱なユーザーグループに大きな利益をもたらすもの — は、最高水準のアクセシビリティ実務を意味します。トルコ市場においてデジタルインクルージョンへのコミットメントを示したい組織や、将来のより厳格な規制を見据えている組織にとって、2.2.6を「任意の理想」ではなく「実務的な実装目標」として扱うことは、大きなメリットがあります。