WCAG 2.2.4: Interruptions

What This Rule Means

WCAG 2.2.4: Interruptions is a Level AAA success criterion under Guideline 2.2 (Enough Time). It states: "Interruptions can be postponed or suppressed by the user, except interruptions involving an emergency." In practical terms, this means that any content, alert, notification, dialog, or update that appears without being directly initiated by the user must offer that user a mechanism to defer or disable it — unless the interruption communicates a genuine emergency such as a fire alarm, life-threatening medical alert, or critical system failure.

An interruption, in the WCAG sense, is any event that occurs independently of the user's current action and diverts attention from what the user is doing. This includes but is not limited to: toast notifications, push alerts, chat widgets that pop open automatically, status banners that refresh or change, auto-playing media, live region announcements injected by JavaScript, modal dialogs triggered on a timer, and cookie consent banners that appear mid-session. The criterion does not prohibit these patterns outright; it requires that users are given control over them.

A page passes 2.2.4 when every non-emergency interruption has at least one of the following: a user-accessible setting that disables the interruption before it fires, a mechanism within the interruption itself to dismiss or postpone it, or a global site-level preference that suppresses such interruptions entirely. A page fails when interruptions appear automatically, offer no dismiss or postpone mechanism, and do not relate to an emergency. For example, a live chat bubble that expands automatically after 10 seconds with no close button, or a notification banner that cycles through marketing messages and cannot be stopped, would both fail.

The one explicitly defined exception is emergencies. If content must interrupt the user to communicate danger to health, safety, or life — for instance, a hospital portal that pushes a critical medication alert — that interruption may override the user's preferences. This exception is intentionally narrow; routine marketing messages, session timeout warnings with ample time remaining, and low-priority status updates do not qualify as emergencies.

Because WCAG 2.2.4 is Level AAA, it is not required for baseline conformance claims, but it is a meaningful standard for organizations committed to full inclusion. It applies to all web content: desktop and mobile web applications, single-page applications that use JavaScript-driven notifications, and progressive web apps that leverage the Web Notifications API.

Why It Matters

Unexpected interruptions on a webpage are not merely annoying — for many users, they represent a serious barrier to completing tasks and, in some cases, a direct health risk.

Users with cognitive and attention-related disabilities — including ADHD, traumatic brain injury, autism spectrum conditions, and dementia — rely heavily on a stable, predictable environment to maintain focus. A sudden notification or animated alert can break their concentration entirely, causing them to lose track of a multi-step process such as completing a benefits application, reviewing a medical record, or filling out a tax form. Reorienting after an interruption may take significantly longer for these users than for neurotypical users, and in some cases they may not be able to recover their place at all.

Screen reader users are particularly affected by dynamic interruptions. When a live region or ARIA alert is injected into the DOM, screen readers such as NVDA, JAWS, and VoiceOver are designed to announce it immediately, interrupting whatever the assistive technology was currently reading. If a user is listening to a long paragraph of important instructions and a marketing toast fires mid-sentence, the screen reader abandons the paragraph and announces the notification. The user must then navigate back, find their place, and re-read — a process that is far more burdensome than it sounds for someone navigating by keyboard and audio alone.

Users with anxiety disorders and PTSD may experience physical stress responses — elevated heart rate, loss of focus, or panic — triggered by sudden, unexpected visual or auditory changes. The unpredictability of an uncontrolled interruption environment can make some websites functionally unusable for these populations.

Users with epilepsy or vestibular disorders can be harmed by certain kinds of interruptions, particularly those involving flashing or rapid movement. While Guideline 2.3 addresses seizure risks specifically, animated notification banners and auto-playing video notifications that appear unexpectedly intersect with both criteria.

Consider a concrete scenario: a user with ADHD is using an online banking portal to transfer money between accounts. They are carefully reviewing the transfer amount and destination account number. A promotional offer notification slides in from the bottom-right corner, triggering a screen reader announcement and an animated entrance. The user loses their place, cannot find the dismiss button because the animation has drawn focus away, and accidentally submits the wrong amount. This is not a hypothetical edge case — it is a predictable outcome of ignoring this criterion.

Beyond disability, uncontrolled interruptions also harm usability for all users, increase bounce rates (users simply leave sites that bombard them), and can reduce conversion on the very actions the interruptions were intended to promote. From an SEO perspective, high bounce rates and low session durations are correlated with poorer search ranking signals, meaning accessibility and business performance are aligned here.

Related Axe-core Rules

WCAG 2.2.4 requires manual testing. Automated tools, including axe-core, cannot reliably detect whether a site produces uncontrollable interruptions, because doing so would require the tool to: observe all dynamic content injected during a user session, assess whether each injection was user-initiated, evaluate whether a dismiss or postpone mechanism exists and is accessible, and determine whether the content qualifies as an emergency. These are contextual, behavioral judgments that fall outside the scope of static DOM analysis.

• Manual testing required — Interruption control: Testers must manually interact with the page over a period of time to observe whether any content updates, notifications, dialogs, or media begin without user initiation. For each interruption observed, the tester must verify that an accessible mechanism exists to postpone or suppress it, that this mechanism itself is keyboard-accessible and screen-reader-announced, and that the interruption does not recur after dismissal without the user re-enabling it.
• Manual testing required — Live region assessment: Pages using aria-live, role='alert', or role='status' must be reviewed manually to determine whether announcements are triggered by user actions (acceptable) or by time-based or server-push events (potentially non-compliant). An automated tool can flag the presence of live regions but cannot determine whether they produce unexpected interruptions during a real user session.
• Manual testing required — Notification API usage: Web applications that request permission to send browser-level push notifications must offer a clear mechanism for the user to manage or suppress these notifications from within the web application itself, not merely relying on browser-level controls. This requires manual inspection of the notification permission flow and the availability of in-app notification preferences.

How to Test

1. Run an automated scan as a baseline. Open the page in Chrome or Firefox and run axe DevTools or Lighthouse. While neither tool has a dedicated rule for 2.2.4, the automated scan will flag related issues: missing roles on dynamic content, improperly configured live regions, and focus management problems in dialogs. Note any aria-live regions or role='alert' elements flagged, as these will need manual follow-up.
2. Observe the page passively for at least two to three minutes. Without clicking anything, watch and listen for any content that changes, appears, or announces itself. Use a screen reader running in the background (NVDA with Firefox, or VoiceOver with Safari on macOS) and listen for any announcements that were not triggered by your action. Note each interruption, its timing, and its content.
3. Test interactive flows that commonly trigger notifications. Log into the application if applicable, navigate to a form or multi-step process, and begin filling it out slowly. Note any interruptions that occur: session timeout warnings, chat invitations, promotional banners, progress updates, or subscription prompts. For each, attempt to dismiss or postpone it using only the keyboard (Tab, Escape, Enter, Space). Verify that focus returns to a logical location after dismissal.
4. Test with NVDA and Firefox. Enable NVDA, open Firefox, and navigate the page. Listen carefully for any speech output that interrupts your current reading. If an automated notification fires, attempt to dismiss it using keyboard controls and verify that NVDA announces the dismissal confirmation or that focus returns appropriately.
5. Test with JAWS and Chrome. Repeat the passive observation and interactive flow tests using JAWS with Chrome. JAWS and NVDA handle live regions differently, so it is important to test both to ensure that interruptions are announced consistently and that dismiss mechanisms work in both screen readers.
6. Test with VoiceOver and Safari on iOS. On a mobile device or simulator, use VoiceOver with Safari to navigate the page. Swipe through content and observe whether any interruptions occur. Test the dismiss mechanism using touch gestures (double-tap to activate) and verify that focus returns to a meaningful location.
7. Check for a notification preference setting. Look for a user profile, settings panel, or accessibility preferences section within the application. Verify that a control exists to suppress or configure notifications globally, and test that enabling this setting actually prevents interruptions from occurring during a subsequent session.
8. Review JavaScript source or network activity. In browser DevTools, observe the Network and Console tabs during the session. Look for WebSocket connections, polling intervals, or setTimeout/setInterval calls that inject content into the DOM. Each of these is a potential source of interruptions and should be traced to ensure user control is implemented.

How to Fix

Auto-opening chat widget — Incorrect

<!-- 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>

Auto-opening chat widget — Correct

<!-- 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>

Uncontrollable marketing toast notification — Incorrect

<!-- 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>

Uncontrollable marketing toast notification — Correct

<!-- 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>

Session timeout modal without user control — Incorrect

<!-- 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>

Session timeout modal without user control — Correct

<!-- 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>

Common Mistakes

• Using role='alert' on promotional or low-priority messages. The alert role signals urgency to screen readers and causes immediate interruption of reading. Marketing messages, tips, and feature announcements should use role='status' or aria-live='polite' instead, which announces content only after the screen reader finishes its current output.
• Providing a close button that is only visible on hover or focus, making it practically inaccessible. If the dismiss mechanism requires the user to hover with a mouse to reveal it, keyboard-only users and screen reader users cannot see or reach it. The dismiss button must always be visible, or at minimum always reachable via keyboard Tab order.
• Returning focus to document.body after dismissing a notification. When a notification or dialog is dismissed, focus must return to a meaningful, contextually appropriate element — typically the element the user was interacting with before the interruption appeared. Dropping focus on body forces screen reader users to re-navigate the entire page.
• Firing multiple aria-live regions simultaneously. When several live regions update at the same time, screen readers queue or drop announcements unpredictably. Each interruption should be managed carefully so that only one live region fires at a time, and updates are batched where possible.
• Treating the browser's native notification permission prompt as sufficient user control. The browser permission dialog for the Web Notifications API operates at the OS level, not the application level. WCAG 2.2.4 requires that users can manage notifications from within the web application itself, not just by blocking the site at the browser level.
• Resetting a dismissed notification on every page load. If a user dismisses a notification and it reappears the next time they navigate to the same page or another page on the site, the dismiss action was meaningless. Preferences should persist for at least the session using sessionStorage, or permanently using localStorage or a server-side preference.
• Using setInterval to cycle through rotating banners or tips without a pause control. Rotating content that refreshes on a timer is an interruption. If the content changes while a screen reader user is reading it, the announcement will restart. These carousels and rotating banners require a play/pause control and must not loop indefinitely without user consent.
• Injecting a notification into the DOM at a position that causes unexpected scroll jumps. If a notification banner is injected at the top of the page and the page shifts down, users lose their visual reading position. Notifications should be injected in a way that does not affect the layout of content the user is currently viewing, typically using fixed or absolute positioning.
• Assuming that a short auto-dismiss timer satisfies the criterion. A toast that disappears after five seconds does not give users meaningful control — many users cannot read, process, or respond to content that quickly, particularly those with cognitive disabilities or those using screen readers. Providing only an auto-dismiss timer without a user-controlled dismiss button is non-compliant.
• Failing to test interruption behavior when the user's operating system or browser has reduced motion or notification preferences enabled. Some users set OS-level preferences for reduced motion or suppressed notifications. These signals should be respected by the application, and developers should test with prefers-reduced-motion: reduce media query active to ensure animated interruptions are suppressed appropriately.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette (No. 32933) on June 21, 2025, establishes a binding web accessibility framework for a broad range of organizations operating in Turkey. The circular adopts WCAG 2.2 as its technical reference standard and mandates conformance for covered entities. The entity types explicitly covered by the circular include public institutions and agencies, e-commerce platforms, banks and financial service providers, hospitals and health service organizations, telecommunications companies with 200,000 or more subscribers, licensed travel agencies, private transport companies, and private schools operating under authorization from the Ministry of National Education (MoNE).

WCAG 2.2.4: Interruptions is a Level AAA criterion, which means it is not among the baseline conformance requirements under Presidential Circular 2025/10 for most covered entities. Organizations that achieve and declare Level A and Level AA conformance are considered legally compliant with the circular's minimum requirements. However, Level AAA criteria such as 2.2.4 carry significant practical and reputational weight in the Turkish market context.

Several of the covered entity types — particularly hospitals, banks, and public institutions — serve user populations with elevated rates of cognitive and neurological conditions, anxiety disorders, and older age-related attention difficulties. For these organizations, uncontrolled interruptions in digital interfaces represent not just an accessibility failure but a potential patient safety or financial harm risk. A hospital patient portal that fires uncontrollable medication reminders or appointment notifications during a critical form-completion flow, or a banking application that displays unsuppressable promotional banners during a transaction review, creates real-world harm for users in these groups.

For organizations in Turkey seeking to demonstrate leadership in digital accessibility — particularly those pursuing voluntary WCAG 2.2 Level AAA declarations, responding to public procurement accessibility requirements, or targeting European markets where the European Accessibility Act (EAA) sets a higher standard — implementing 2.2.4 is a meaningful differentiator. The Accsible overlay SDK supports organizations in meeting these higher standards by providing configurable notification management features, user preference persistence, and accessibility-aware widget behaviors that align with both Turkish regulatory expectations and international best practice.