WCAG 2.2.4: 中断

この規定の意味

WCAG 2.2.4: Interruptions（中断）は、ガイドライン 2.2（十分な時間）の下にあるレベル AAA の達成基準です。そこでは次のように述べられています。「緊急事態に関わる中断を除き、中断は利用者によって延期または抑制できる。」 実務的には、利用者が直接開始していないあらゆるコンテンツ、アラート、通知、ダイアログ、更新は、その利用者がそれを延期または無効化できる仕組みを提供しなければならないことを意味します — ただし、その中断が火災報知、生命に関わる医療アラート、重大なシステム障害などの真の緊急事態を伝える場合を除きます。

WCAG の意味での中断とは、利用者の現在の操作とは独立して発生し、利用者が行っていることから注意をそらすあらゆる事象を指します。これには、トースト通知、プッシュアラート、自動的に開くチャットウィジェット、更新・変更されるステータスバナー、自動再生メディア、JavaScript によって挿入されるライブリージョンのアナウンス、タイマーで起動されるモーダルダイアログ、セッションの途中で表示されるクッキー同意バナーなどが含まれますが、これらに限定されません。この達成基準は、これらのパターンを全面的に禁止するものではなく、利用者にそれらを制御する手段を与えることを求めています。

ページが 2.2.4 に適合しているのは、すべての非緊急の中断について、少なくとも次のいずれかがある場合です。中断が発生する前にそれを無効化できる利用者向け設定、中断自体の中にそれを却下または延期する仕組み、またはそのような中断を完全に抑制するサイト全体の共通設定。ページが不適合となるのは、中断が自動的に現れ、却下や延期の仕組みを提供せず、かつ緊急事態に関係しない場合です。たとえば、10 秒後に自動的に展開し閉じるボタンのないライブチャットバブルや、マーケティングメッセージを循環表示し停止できない通知バナーは、いずれも不適合となります。

明示的に定義されている唯一の例外は緊急事態です。健康、安全、生命に関わる危険を伝えるためにコンテンツが利用者を中断しなければならない場合 — たとえば、病院ポータルが重大な投薬アラートをプッシュする場合 — その中断は利用者の設定を上書きしても構いません。この例外は意図的に範囲が狭く設定されています。通常のマーケティングメッセージ、十分な残り時間があるセッションタイムアウト警告、優先度の低いステータス更新などは、緊急事態には該当しません。

WCAG 2.2.4 はレベル AAA であるため、ベースラインの適合主張に必須ではありませんが、完全なインクルージョンに取り組む組織にとっては意味のある基準です。これはすべてのウェブコンテンツに適用されます。デスクトップおよびモバイルのウェブアプリケーション、JavaScript 駆動の通知を用いるシングルページアプリケーション、Web Notifications API を活用するプログレッシブウェブアプリなどです。

なぜ重要か

ウェブページ上の予期しない中断は、単に迷惑なだけではありません — 多くの利用者にとっては、タスク完了への重大な障壁であり、場合によっては直接的な健康リスクにもなります。

認知・注意に関連する障害のある利用者 — ADHD、外傷性脳損傷、自閉スペクトラム症、認知症などを含む — は、集中を維持するために安定した予測可能な環境に大きく依存しています。突然の通知やアニメーション付きアラートは、集中を完全に途切れさせ、給付申請の完了、診療記録の確認、税フォームの記入といった複数ステップのプロセスの流れを見失わせることがあります。中断後に再び状況を把握するには、神経学的に典型的な利用者よりもはるかに長い時間がかかる場合があり、場合によっては元の位置に戻れないこともあります。

スクリーンリーダー利用者は、動的な中断の影響を特に受けやすいです。ライブリージョンや ARIA アラートが DOM に挿入されると、NVDA、JAWS、VoiceOver などのスクリーンリーダーは、それを即座にアナウンスするよう設計されており、支援技術が現在読み上げている内容を中断します。利用者が重要な説明文の長い段落を聞いている最中にマーケティングトーストが文の途中で発火すると、スクリーンリーダーは段落の読み上げを中止し、通知をアナウンスします。その後、利用者は元の場所に戻り、位置を探し、再度読み直さなければなりません — キーボードと音声だけで操作している人にとって、このプロセスは想像以上に負担が大きいものです。

不安障害や PTSD のある利用者は、突然の予期しない視覚的・聴覚的変化によって、心拍数の上昇、集中力の喪失、パニックなどの身体的ストレス反応を経験することがあります。制御されていない中断環境の予測不可能性は、これらの人々にとって一部のウェブサイトを事実上利用不能にしてしまうことがあります。

てんかんや前庭障害のある利用者は、特に点滅や急速な動きを伴う特定の種類の中断によって害を受ける可能性があります。ガイドライン 2.3 は発作リスクを特に扱っていますが、アニメーション付き通知バナーや、予期せず表示される自動再生ビデオ通知は、両方の達成基準にまたがる問題です。

具体的なシナリオを考えてみましょう。ADHD のある利用者が、オンラインバンキングポータルで口座間の振込を行っています。振込金額と振込先口座番号を慎重に確認しているところです。右下からプロモーションオファーの通知がスライドインし、スクリーンリーダーのアナウンスとアニメーション付きの表示が行われます。利用者は位置を見失い、アニメーションによってフォーカスがそらされたために閉じるボタンを見つけられず、誤った金額で送金を送信してしまいます。これは仮想的なレアケースではなく、この達成基準を無視した場合に予測可能な結果です。

障害の有無にかかわらず、制御されていない中断はすべての利用者のユーザビリティを損ない、直帰率を高め（利用者は大量の中断を行うサイトから単に離脱します）、中断によって促進しようとしていた行動のコンバージョンをむしろ低下させることがあります。SEO の観点からも、高い直帰率や短いセッション時間は検索ランキングシグナルの悪化と相関しており、この点でアクセシビリティとビジネスパフォーマンスは一致しています。

関連する axe-core のルール

WCAG 2.2.4 は手動テストを必要とします。axe-core を含む自動化ツールは、サイトが制御不能な中断を発生させるかどうかを確実に検出することができません。なぜなら、そのためにはツールが、ユーザーセッション中に挿入されるすべての動的コンテンツを観察し、それぞれの挿入が利用者によって開始されたものかどうかを評価し、却下または延期の仕組みが存在しアクセシブルかどうかを判断し、そのコンテンツが緊急事態に該当するかどうかを判定する必要があるからです。これらは文脈依存かつ行動ベースの判断であり、静的な DOM 解析の範囲を超えています。

• 手動テストが必要 — 中断制御: テスターは一定時間ページと手動でやり取りし、コンテンツの更新、通知、ダイアログ、メディアが利用者の操作なしに開始されるかどうかを観察する必要があります。観察された各中断について、延期または抑制するためのアクセシブルな仕組みが存在すること、その仕組み自体がキーボードで操作可能でスクリーンリーダーにアナウンスされること、中断が却下後に利用者が再度有効化しない限り再発しないことを確認しなければなりません。
• 手動テストが必要 — ライブリージョンの評価: aria-live、role='alert'、role='status' を使用しているページは、アナウンスが利用者の操作によってトリガーされているか（許容される）、時間ベースまたはサーバープッシュイベントによってトリガーされているか（非適合の可能性）を判断するために手動でレビューする必要があります。自動化ツールはライブリージョンの存在をフラグ付けすることはできますが、実際のユーザーセッション中に予期しない中断を発生させるかどうかを判断することはできません。
• 手動テストが必要 — Notification API の使用: ブラウザレベルのプッシュ通知送信の許可を求めるウェブアプリケーションは、ブラウザレベルの制御にのみ依存するのではなく、ウェブアプリケーション内からこれらの通知を管理または抑制するための明確な仕組みを提供しなければなりません。これは、通知許可フローとアプリ内通知設定の有無を手動で確認することを必要とします。

テスト方法

1. ベースラインとして自動スキャンを実行する。 Chrome または Firefox でページを開き、axe DevTools または Lighthouse を実行します。どちらのツールにも 2.2.4 専用のルールはありませんが、自動スキャンは関連する問題 — 動的コンテンツのロール不足、不適切に構成されたライブリージョン、ダイアログにおけるフォーカス管理の問題 — を検出します。フラグ付けされた aria-live リージョンや role='alert' 要素をメモしておき、これらについては手動でフォローアップします。
2. ページを 2〜3 分間は受動的に観察する。 何もクリックせずに、変化する、表示される、または自らアナウンスするコンテンツがないか視覚的・聴覚的に観察します。バックグラウンドでスクリーンリーダー（Firefox と NVDA、または macOS の Safari と VoiceOver）を実行し、自分の操作によってトリガーされていないアナウンスがないかを聞き取ります。各中断、そのタイミング、内容を記録します。
3. 通知をトリガーしがちなインタラクティブフローをテストする。 該当する場合はアプリケーションにログインし、フォームや複数ステップのプロセスに移動して、ゆっくりと入力を開始します。セッションタイムアウト警告、チャット招待、プロモーションバナー、進捗更新、購読プロンプトなど、発生する中断を記録します。それぞれについて、キーボードのみ（Tab、Escape、Enter、Space）で却下または延期できるか試し、却下後にフォーカスが論理的な位置に戻ることを確認します。
4. NVDA と Firefox でテストする。 NVDA を有効にし、Firefox でページに移動します。現在の読み上げを中断する音声出力がないか注意深く聞きます。自動通知が発火した場合、キーボード操作でそれを却下し、NVDA が却下の確認をアナウンスするか、フォーカスが適切に戻ることを確認します。
5. JAWS と Chrome でテストする。 JAWS と Chrome を使用して、受動的観察とインタラクティブフローのテストを繰り返します。JAWS と NVDA はライブリージョンの扱いが異なるため、両方でテストして、中断が一貫してアナウンスされ、却下の仕組みが両方のスクリーンリーダーで機能することを確認することが重要です。
6. iOS の VoiceOver と Safari でテストする。 モバイルデバイスまたはシミュレータ上で、VoiceOver と Safari を使用してページをナビゲートします。コンテンツをスワイプし、中断が発生するかどうかを観察します。タッチジェスチャー（ダブルタップでアクティブ化）を使って却下の仕組みをテストし、フォーカスが意味のある位置に戻ることを確認します。
7. 通知設定の有無を確認する。 アプリケーション内にユーザープロファイル、設定パネル、アクセシビリティ設定セクションがないか探します。通知をグローバルに抑制または設定できるコントロールが存在することを確認し、その設定を有効にした後のセッションで中断が実際に発生しなくなることをテストします。
8. JavaScript ソースまたはネットワークアクティビティを確認する。 ブラウザの DevTools で、セッション中の Network タブと Console タブを観察します。WebSocket 接続、ポーリング間隔、DOM にコンテンツを挿入する setTimeout/setInterval 呼び出しを探します。これらはすべて中断の潜在的な原因であり、利用者による制御が実装されているかどうかを確認する必要があります。

修正方法

自動で開くチャットウィジェット — 不適切な例

<!-- Chat widget opens automatically after 10 seconds with no close button -->
<div id='chat-widget' role='dialog' aria-label='Live chat'>
  <p>Hi! Can we help you today?</p>
  <button>Start chat</button>
</div>

<script>
  setTimeout(function() {
    document.getElementById('chat-widget').style.display = 'block';
  }, 10000);
</script>

自動で開くチャットウィジェット — 適切な例

<!-- Chat widget includes a dismiss button and respects a user preference -->
<div id='chat-widget' role='dialog' aria-label='Live chat' aria-modal='true'>
  <p>Hi! Can we help you today?</p>
  <button id='chat-start'>Start chat</button>
  <!-- Dismiss button allows user to postpone the interruption -->
  <button id='chat-dismiss' aria-label='Dismiss chat offer'>No thanks</button>
</div>

<script>
  // Check whether the user has previously dismissed the chat offer
  if (!sessionStorage.getItem('chat-dismissed')) {
    setTimeout(function() {
      var widget = document.getElementById('chat-widget');
      widget.removeAttribute('hidden');
      // Move focus into the dialog so screen reader users are aware of it
      document.getElementById('chat-dismiss').focus();
    }, 10000);
  }

  document.getElementById('chat-dismiss').addEventListener('click', function() {
    // Suppress for the remainder of the session
    sessionStorage.setItem('chat-dismissed', 'true');
    var widget = document.getElementById('chat-widget');
    widget.setAttribute('hidden', '');
    // Return focus to the element the user was on before the interruption
    document.getElementById('main-content').focus();
  });
</script>

制御不能なマーケティングトースト通知 — 不適切な例

<!-- Toast fires every 30 seconds, no way to stop it -->
<div role='alert' id='promo-toast'>
  <p>Use code SAVE20 for 20% off your next order!</p>
</div>

<script>
  setInterval(function() {
    document.getElementById('promo-toast').style.display = 'block';
    setTimeout(function() {
      document.getElementById('promo-toast').style.display = 'none';
    }, 5000);
  }, 30000);
</script>

制御不能なマーケティングトースト通知 — 適切な例

<!-- Toast fires once, includes a dismiss control, and respects a preference -->
<div role='status' id='promo-toast' hidden>
  <p>Use code SAVE20 for 20% off your next order!</p>
  <!-- Dismiss button suppresses future promos in this session -->
  <button id='promo-dismiss' aria-label='Dismiss promotion'>&times;</button>
</div>

<script>
  // Only show once, and only if the user has not opted out
  if (!localStorage.getItem('promos-suppressed')) {
    setTimeout(function() {
      document.getElementById('promo-toast').removeAttribute('hidden');
    }, 30000);
  }

  document.getElementById('promo-dismiss').addEventListener('click', function() {
    // Suppress all future promotional interruptions permanently
    localStorage.setItem('promos-suppressed', 'true');
    document.getElementById('promo-toast').setAttribute('hidden', '');
  });
</script>

利用者制御のないセッションタイムアウトモーダル — 不適切な例

<!-- Modal fires automatically, traps focus with no postpone option -->
<div id='timeout-modal' role='dialog' aria-label='Session expiring'>
  <p>Your session will expire in 60 seconds.</p>
  <button id='logout-now'>Log out</button>
</div>

利用者制御のないセッションタイムアウトモーダル — 適切な例

<!-- Modal provides both a continue option and a postpone option,
     and announces itself clearly to screen readers -->
<div id='timeout-modal' role='alertdialog'
     aria-labelledby='timeout-heading'
     aria-describedby='timeout-description'
     aria-modal='true'>
  <h2 id='timeout-heading'>Session Expiring Soon</h2>
  <p id='timeout-description'>
    Your session will expire in <span id='countdown'>5 minutes</span>.
    Would you like to continue, or shall we log you out now?
  </p>
  <button id='continue-session'>Continue session</button>
  <button id='logout-now'>Log out now</button>
  <!-- Postpone option gives the user meaningful control -->
  <button id='remind-later'>Remind me in 5 more minutes</button>
</div>

よくある間違い

• プロモーションや優先度の低いメッセージに role='alert' を使用すること。 alert ロールはスクリーンリーダーに緊急性を示し、現在の読み上げを即座に中断させます。マーケティングメッセージ、ヒント、機能のお知らせには、role='status' や aria-live='polite' を使用すべきであり、これらはスクリーンリーダーが現在の出力を終えた後にのみコンテンツをアナウンスします。
• ホバーやフォーカス時にのみ表示される閉じるボタンを提供し、実質的にアクセス不能にしてしまうこと。 却下の仕組みが、マウスでホバーしたときにのみ表示される場合、キーボードのみの利用者やスクリーンリーダー利用者はそれを見たり到達したりできません。却下ボタンは常に表示されている必要があり、少なくともキーボードの Tab 順で常に到達可能でなければなりません。
• 通知を却下した後にフォーカスを document.body に戻すこと。 通知やダイアログを却下した際、フォーカスは意味があり文脈的に適切な要素 — 通常は中断が発生する前に利用者が操作していた要素 — に戻る必要があります。フォーカスを body に落としてしまうと、スクリーンリーダー利用者はページ全体を再度ナビゲートしなければなりません。
• 複数の aria-live リージョンを同時に発火させること。 複数のライブリージョンが同時に更新されると、スクリーンリーダーはアナウンスを予測不能な形でキューに入れたり破棄したりします。各中断は慎重に管理し、同時に発火するライブリージョンは 1 つにとどめ、可能な限り更新をまとめるべきです。
• ブラウザのネイティブな通知許可プロンプトを十分な利用者制御とみなすこと。 Web Notifications API のブラウザ許可ダイアログは OS レベルで動作しており、アプリケーションレベルではありません。WCAG 2.2.4 は、利用者がブラウザレベルでサイトをブロックするだけでなく、ウェブアプリケーション内から通知を管理できることを求めています。
• 却下された通知をページ読み込みのたびにリセットしてしまうこと。 利用者が通知を却下したにもかかわらず、同じページやサイト内の別ページに移動するたびに再び表示される場合、その却下操作は意味を持ちません。設定は、少なくとも sessionStorage を用いてセッション中は、あるいは localStorage やサーバー側の設定を用いて永続的に保持されるべきです。
• 一時停止コントロールなしに、回転バナーやヒントを setInterval で循環させること。 タイマーで更新される回転コンテンツは中断です。スクリーンリーダー利用者が読んでいる最中にコンテンツが変化すると、アナウンスは最初からやり直されます。これらのカルーセルや回転バナーには再生/一時停止コントロールが必要であり、利用者の同意なしに無期限にループしてはなりません。
• 予期しないスクロールジャンプを引き起こす位置に通知を DOM に挿入すること。 通知バナーがページ上部に挿入されてページ全体が下にずれると、利用者は視覚的な読み位置を失います。通知は、利用者が現在見ているコンテンツのレイアウトに影響を与えない方法で挿入されるべきであり、通常は fixed もしくは absolute ポジショニングを用います。
• 短い自動消去タイマーが達成基準を満たすと誤解すること。 5 秒後に消えるトーストは、利用者に意味のある制御を与えていません。多くの利用者は、特に認知障害のある人やスクリーンリーダー利用者など、これほど短時間ではコンテンツを読み、理解し、対応することができません。利用者が制御する却下ボタンを提供せず、自動消去タイマーだけに頼ることは非適合です。
• 利用者の OS やブラウザで動きの軽減や通知抑制の設定が有効な場合の中断動作をテストしないこと。 一部の利用者は、動きの軽減や通知抑制の OS レベル設定を有効にしています。アプリケーションはこれらのシグナルを尊重すべきであり、prefers-reduced-motion: reduce メディアクエリを有効にした状態でテストし、アニメーション付きの中断が適切に抑制されることを確認する必要があります。

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

2025 年 6 月 21 日付官報（No. 32933）で公布されたトルコ大統領通達 2025/10 は、トルコで事業を行う幅広い組織に対して拘束力のあるウェブアクセシビリティ枠組みを確立しています。この通達は WCAG 2.2 を技術的な参照標準として採用し、対象組織に適合を義務付けています。通達で明示的に対象とされている組織種別には、公的機関・政府機関、e コマースプラットフォーム、銀行および金融サービス提供者、病院および医療サービス組織、20 万人以上の加入者を持つ通信会社、認可を受けた旅行代理店、民間輸送会社、国民教育省（MoNE）の認可の下で運営される私立学校が含まれます。

WCAG 2.2.4: Interruptions はレベル AAA の達成基準であり、そのため大統領通達 2025/10 の下で大半の対象組織に求められるベースライン適合要件には含まれていません。レベル A およびレベル AA の適合を達成し宣言した組織は、通達の最低要件を法的に満たしているとみなされます。しかし、2.2.4 のようなレベル AAA の達成基準は、トルコ市場の文脈において実務的にも評判の面でも大きな意味を持ちます。

対象組織のいくつか — 特に病院、銀行、公的機関 — は、認知・神経学的な状態、不安障害、高齢に伴う注意困難の割合が高い利用者層にサービスを提供しています。これらの組織にとって、デジタルインターフェースにおける制御されていない中断は、単なるアクセシビリティの欠如ではなく、患者の安全や財務的な損害リスクにもなり得ます。重要なフォーム入力フローの最中に制御不能な投薬リマインダーや予約通知を発火させる病院の患者ポータルや、取引確認中に抑制不能なプロモーションバナーを表示する銀行アプリケーションは、これらのグループの利用者に現実の被害をもたらします。

トルコにおいてデジタルアクセシビリティのリーダーシップを示そうとする組織 — 特に、任意で WCAG 2.2 レベル AAA の宣言を目指す組織、公的調達のアクセシビリティ要件に対応する組織、より高い基準を設定する欧州アクセシビリティ法（EAA）を適用する欧州市場をターゲットとする組織 — にとって、2.2.4 の実装は意味のある差別化要因となります。Accsible overlay SDK は、設定可能な通知管理機能、利用者設定の永続化、トルコの規制上の期待と国際的なベストプラクティスの両方に整合するアクセシビリティ対応ウィジェット動作を提供することで、これらの高い基準の達成を支援します。