Level AAA

Author- or server-initiated interruptions -- chat widgets, push permission prompts, auto-opening modals, assertive live regions -- must be postponable or suppressible by the user, except for genuine emergencies.

2.2.4 Interruptions

In Plain Language

2.2.4 Interruptions (Level AAA) requires that any author- or server-initiated interruption can be postponed or suppressed by the user, except where the interruption involves an emergency[1]. "Interruption" covers the full class of content that arrives without the user asking for it: chat widgets that pop over the page 30 seconds after load, push-notification permission prompts on first visit, marketing modals that fire on scroll-depth or exit-intent, cookie banners that trap focus, auto-refreshing content, and live-region announcements pushed by the server.

The emergency carve-out is narrow. W3C defines it as "a sudden, unexpected situation or occurrence that requires immediate action to preserve health, safety, or property" -- civil alerts, safety warnings, connection-loss or data-loss notices[1]. Newsletter sign-ups, "would you like to chat?" prompts, and feature announcements do not qualify.

Why It Matters

  • An unexpected modal or toast pulls focus away from the task the user was performing. For users with attention-related cognitive and learning disabilities, reacquiring the prior context is not free -- it costs the working-memory state that was holding the task together.
  • Screen-reader users hear interruptions as announcement preemption. A region marked aria-live="assertive" (or role="alert") tells the AT to interrupt whatever it is currently speaking and read the new content immediately. If the update is not an emergency, the user loses their place in the prior announcement and must re-navigate to recover it.
  • Auto-opening dialogs that steal focus on page load break the relationship between user action and UI response. A user with a cognitive disability has no causal model for why the dialog appeared, and dismissing it may not be obvious if the close affordance is a small icon or requires Esc.
  • Low-vision users running at high magnification may have the interrupting element render entirely outside the viewport, so a modal they cannot see is trapping focus on a control they cannot find.

Examples

Do: Notification preferences that let users suppress alerts

Notification settings panel:

<fieldset>

<legend>Notification preferences</legend>

<label><input type="checkbox"> Pause all notifications</label>

✔ Users can suppress non-emergency interruptions

<fieldset>
  <legend>Notification preferences</legend>
  <label>
    <input type="checkbox" name="pause-all">
    Pause all notifications
  </label>
  <label>
    <input type="checkbox" name="pause-marketing">
    Suppress promotional alerts
  </label>
  <p>Emergency alerts cannot be disabled.</p>
</fieldset>
Do: Polite live region for non-urgent updates

Non-urgent status update:

<div role="status" aria-live="polite">

3 new messages waiting</div>

✔ Polite live region waits for the user to finish before announcing

<!-- Non-urgent: use polite so it waits
     for the screen reader to finish -->
<div role="status" aria-live="polite">
  3 new messages waiting
</div>

<!-- Emergency: assertive is appropriate -->
<div role="alert" aria-live="assertive">
  Server connection lost. Reconnecting...
</div>
Don't: Forced modal that interrupts with no way to defer

Promotional pop-up on page load:

<div role="dialog" aria-modal="true">

Sign up for our newsletter!</div>

✘ Non-emergency modal interrupts with no option to postpone or suppress

Don't: Assertive live region for non-urgent content

Chat notification using assertive:

<div aria-live="assertive">New message from Alex</div>

✘ Non-emergency alert uses assertive, hijacking screen reader focus with no way to defer

How to Fix It

  1. Defer non-emergency interruptions to an explicit user action. Do not open the chat widget on a timer -- open it when the user clicks a launcher button. Do not request notification permission on first visit -- request it after the user takes an action that implies they want notifications (e.g. clicking "Notify me when this ships"). Do not fire marketing modals on scroll-depth or exit-intent; put the offer in the page flow instead.
  2. Use aria-live="polite" for status updates, not assertive. A polite live region queues behind the screen reader's current utterance; an assertive region preempts it. "New message from Alex" is a status update, not an emergency, so it belongs in a polite region (or role="status", which has an implicit polite setting)[1].
  3. Reserve aria-live="assertive" and role="alert" for the emergency class. Session-about-to-expire warnings, connection loss, data-loss risk, and safety-critical messages qualify. A sale ending in 10 minutes does not.
  4. Give users a global suppression control. A Do Not Disturb toggle, a notification-preferences panel, or an OS-level respect for prefers-reduced-motion and quiet-hours settings all satisfy the requirement that users can suppress non-emergency interruptions.
  5. Stop auto-refreshing content that announces itself. A feed that refetches every 15 seconds and updates an aria-live region will fire continuous screen-reader announcements. Either drop the announcement, batch updates behind a user-triggered "Show new items" button, or make the refresh interval user-configurable.

References

  1. [1] W3C (2023). Understanding Success Criterion 2.2.4: Interruptions. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/interruptions.html ↩ ↩ ↩