WCAG 2.2.4: Interruptions

Who this helps

The common thread: interruptions cost different users wildly different amounts. Letting each user decide when — and whether — to receive them equalizes that cost.

What counts as an interruption

An interruption is content-initiated, not user-initiated. If the page decides the moment, it is an interruption; if the user asked for it, it is a response. Typical interrupters:

• →Toast and banner notifications announcing messages, promotions, or feature launches.
• →Chat widgets that open themselves or play sounds when an agent 'joins'.
• →Modals that appear on a timer — newsletter signups, exit-intent overlays, rating prompts.
• →Auto-updating content: live feeds, tickers, dashboards, and scores that reflow the page.
• →Automatic page refreshes or redirects that reset scroll position and focus.
• →Scripted focus moves — anything that relocates keyboard focus without a user action.

For each of these you need at least one of two affordances:

Pass and fail examples

Code examples

Let users request updates instead of pushing them

Buffer incoming items and surface a polite, non-focus-stealing control. The user decides the moment of interruption.

<div aria-live="polite">
  <button id="show-new" hidden>Show 12 new stories</button>
</div>
<ol id="feed"><!-- existing stories --></ol>

<script>
  const buffer = [];
  socket.on("story", (story) => {
    buffer.push(story);                       // ✓ buffer, don't inject
    showNew.textContent = `Show ${buffer.length} new stories`;
    showNew.hidden = false;                   // announced politely, focus untouched
  });

  showNew.addEventListener("click", () => {
    feed.prepend(...buffer.map(render));      // ✓ user chose the moment
    buffer.length = 0;
    showNew.hidden = true;
  });
</script>

A persistent notification-preferences surface

Suppression must be per-category, persistent, and reachable before the first interruption does damage.

<fieldset>
  <legend>Notifications</legend>
  <label>
    <input type="checkbox" name="notif" value="mentions" checked />
    Mentions and replies
  </label>
  <label>
    <input type="checkbox" name="notif" value="tips" />
    Tips and feature announcements
  </label>
  <label>
    <input type="checkbox" name="notif" value="marketing" />
    Offers and promotions
  </label>
  <label>
    <input type="checkbox" name="notif" value="sound" />
    Play a sound with notifications
  </label>
</fieldset>

<script>
  // Respect the stored preference before showing anything
  function maybeNotify(category, payload) {
    const prefs = JSON.parse(localStorage.getItem("notifPrefs") ?? "{}");
    if (prefs[category] === false) return;    // ✓ suppressed by the user
    queueToast(payload);                      // polite live region, no focus move
  }
</script>

Announce without stealing focus

<!-- ✗ role="alert" + focus() for a routine update: maximal interruption -->
<div role="alert" tabindex="-1" id="promo">Check out our new plans!</div>
<script>promo.focus()</script>

<!-- ✓ Routine updates: polite live region, focus stays where the user is -->
<div aria-live="polite" id="status"></div>
<script>status.textContent = "Draft saved";</script>

<!-- ✓ Reserve role="alert" (assertive) for genuine emergencies only -->
<div role="alert">Your session expires in 2 minutes. Extend to keep your work.</div>

Common failures

• ✗Timed marketing modals (newsletter, discount, exit-intent) with no mechanism to postpone or permanently suppress them.
• ✗Auto-updating feeds, tickers, and dashboards with no pause or 'update on request' option — often a 2.2.2 failure as well.
• ✗Chat and support widgets that open themselves, play sounds, or take focus when the user has not engaged them.
• ✗Automatic page refresh via meta refresh or scripted reload that the user cannot disable.
• ✗Using assertive live regions (role='alert') for routine, non-emergency messages, forcing screen readers to announce them immediately over the user's current task.
• ✗Notification settings that exist but do not persist, reset on each visit, or fail to cover major interrupting surfaces like in-app announcement dialogs.
• ✗Treating business-important messages (sales, upgrade prompts) as 'emergencies' — the exception covers threats to health, safety, or property, including imminent data loss, and nothing else.

How to test for 2.2.4

1. 1

   Sit on the page and wait

   Load key pages and do nothing for several minutes. Note everything that appears, moves, refreshes, sounds, or changes without your input — each one is an interruption to evaluate.

2. 2

   Work through a task while interruptions fire

   Fill a long form or read a long article while notifications arrive. Check whether focus ever moves without your action and whether your scroll or reading position is disturbed.

3. 3

   Look for postpone and suppress controls

   For every interruption found, verify the user can defer it (notification center, 'show new items', 'remind me later') or disable it (persistent per-category preferences). At least one of the two must exist.

4. 4

   Verify persistence of preferences

   Turn notifications off, reload, clear the session, and revisit. Suppression that silently resets is suppression that does not exist.

5. 5

   Audit the emergency claims

   For any interruption exempted as an emergency, check it against the definition: immediate action needed to preserve health, safety, or property (including the user's data). Session-expiry warnings qualify; promotions never do.

Test with a screen reader running: interruptions that look mild visually are often severe aurally. Continue with the full WCAG 2.2 checklist.

Frequently asked questions