WCAG 2.2.4: Onderbrekingen

Wat Deze Regel Betekent

WCAG 2.2.4: Interruptions is een succescriterium op Niveau AAA onder Richtlijn 2.2 (Voldoende tijd). Het stelt: "Interruptions can be postponed or suppressed by the user, except interruptions involving an emergency." In praktische termen betekent dit dat alle content, waarschuwingen, meldingen, dialogen of updates die verschijnen zonder dat ze direct door de gebruiker zijn geïnitieerd, de gebruiker een mechanisme moeten bieden om ze uit te stellen of uit te schakelen — tenzij de onderbreking een echte noodsituatie communiceert, zoals een brandalarm, een levensbedreigende medische waarschuwing of een kritieke systeemstoring.

Een onderbreking, in de WCAG-betekenis, is elke gebeurtenis die onafhankelijk van de huidige actie van de gebruiker plaatsvindt en de aandacht afleidt van wat de gebruiker aan het doen is. Dit omvat, maar is niet beperkt tot: toastmeldingen, pushmeldingen, chatwidgets die automatisch openen, statusbanners die verversen of veranderen, automatisch afspelende media, live-regio-aankondigingen die door JavaScript worden geïnjecteerd, modale dialogen die door een timer worden geactiveerd, en cookie-toestemmingsbanners die midden in een sessie verschijnen. Het criterium verbiedt deze patronen niet volledig; het vereist dat gebruikers er controle over krijgen.

Een pagina voldoet aan 2.2.4 wanneer elke niet-noodonderbreking ten minste één van de volgende zaken heeft: een door de gebruiker toegankelijke instelling die de onderbreking uitschakelt voordat deze optreedt, een mechanisme binnen de onderbreking zelf om deze te sluiten of uit te stellen, of een globale sitebrede voorkeur die dergelijke onderbrekingen volledig onderdrukt. Een pagina voldoet niet wanneer onderbrekingen automatisch verschijnen, geen mechanisme bieden om ze te sluiten of uit te stellen, en niet gerelateerd zijn aan een noodsituatie. Een live chatballon die bijvoorbeeld automatisch na 10 seconden uitklapt zonder sluitknop, of een meldingsbanner die marketingberichten laat roteren en niet kan worden gestopt, zouden beide niet voldoen.

De ene expliciet gedefinieerde uitzondering zijn noodsituaties. Als content de gebruiker moet onderbreken om gevaar voor gezondheid, veiligheid of leven te communiceren — bijvoorbeeld een ziekenhuisportaal dat een kritieke medicatiewaarschuwing verstuurt — mag die onderbreking de voorkeuren van de gebruiker negeren. Deze uitzondering is bewust smal; routinematige marketingberichten, waarschuwingen voor sessieverloop met ruim voldoende resterende tijd, en statusupdates met lage prioriteit kwalificeren niet als noodsituaties.

Omdat WCAG 2.2.4 Niveau AAA is, is het niet vereist voor basisconformiteitsclaims, maar het is een betekenisvolle norm voor organisaties die zich inzetten voor volledige inclusie. Het is van toepassing op alle webcontent: desktop- en mobiele webapplicaties, single-page applicaties die JavaScript-gestuurde meldingen gebruiken, en progressive web apps die de Web Notifications API benutten.

Waarom Het Belangrijk Is

Onverwachte onderbrekingen op een webpagina zijn niet alleen maar irritant — voor veel gebruikers vormen ze een serieuze barrière om taken te voltooien en in sommige gevallen een direct gezondheidsrisico.

Gebruikers met cognitieve en aandachtsgerelateerde beperkingen — waaronder ADHD, traumatisch hersenletsel, autisme-spectrumcondities en dementie — zijn sterk afhankelijk van een stabiele, voorspelbare omgeving om de focus te behouden. Een plotselinge melding of geanimeerde waarschuwing kan hun concentratie volledig doorbreken, waardoor ze de draad kwijtraken in een meerstapsproces zoals het invullen van een uitkeringsaanvraag, het doornemen van een medisch dossier of het invullen van een belastingformulier. Het hervinden van de oriëntatie na een onderbreking kan voor deze gebruikers aanzienlijk langer duren dan voor neurotypische gebruikers, en in sommige gevallen kunnen ze hun plek helemaal niet meer terugvinden.

Screenreader-gebruikers worden in het bijzonder getroffen door dynamische onderbrekingen. Wanneer een live-regio of ARIA-waarschuwing in de DOM wordt geïnjecteerd, zijn screenreaders zoals NVDA, JAWS en VoiceOver ontworpen om deze onmiddellijk aan te kondigen, waarbij ze alles onderbreken wat de ondersteunende technologie op dat moment aan het voorlezen is. Als een gebruiker luistert naar een lange paragraaf met belangrijke instructies en een marketingtoast wordt halverwege de zin geactiveerd, stopt de screenreader met de paragraaf en kondigt de melding aan. De gebruiker moet dan terug navigeren, zijn plek terugvinden en opnieuw lezen — een proces dat veel belastender is dan het klinkt voor iemand die uitsluitend met toetsenbord en audio navigeert.

Gebruikers met angststoornissen en PTSS kunnen fysieke stressreacties ervaren — verhoogde hartslag, verlies van focus of paniek — die worden getriggerd door plotselinge, onverwachte visuele of auditieve veranderingen. De onvoorspelbaarheid van een omgeving met ongecontroleerde onderbrekingen kan sommige websites feitelijk onbruikbaar maken voor deze groepen.

Gebruikers met epilepsie of vestibulaire stoornissen kunnen schade ondervinden van bepaalde soorten onderbrekingen, met name die met flitsen of snelle beweging. Hoewel Richtlijn 2.3 specifiek het risico op aanvallen behandelt, overlappen geanimeerde meldingsbanners en automatisch afspelende videomeldingen die onverwacht verschijnen met beide criteria.

Neem een concreet scenario: een gebruiker met ADHD gebruikt een online bankportaal om geld tussen rekeningen over te boeken. Diegene controleert zorgvuldig het overboekingsbedrag en het nummer van de doelrekening. Een promotionele meldingsbanner schuift vanuit de rechterbenedenhoek in beeld, triggert een screenreader-aankondiging en een geanimeerde binnenkomst. De gebruiker raakt zijn plek kwijt, kan de sluitknop niet vinden omdat de animatie de aandacht heeft weggetrokken, en verstuurt per ongeluk het verkeerde bedrag. Dit is geen hypothetisch randgeval — het is een voorspelbare uitkomst van het negeren van dit criterium.

Los van beperkingen schaden ongecontroleerde onderbrekingen ook de bruikbaarheid voor alle gebruikers, verhogen ze het bouncepercentage (gebruikers verlaten simpelweg sites die hen bestoken) en kunnen ze de conversie verlagen bij precies de acties die de onderbrekingen moesten promoten. Vanuit SEO-perspectief hangen hoge bouncepercentages en korte sessieduur samen met slechtere zoekrangsignalen, wat betekent dat toegankelijkheid en bedrijfsresultaten hier op één lijn liggen.

Gerelateerde Axe-core-regels

WCAG 2.2.4 vereist handmatig testen. Geautomatiseerde tools, waaronder axe-core, kunnen niet betrouwbaar detecteren of een site ongecontroleerde onderbrekingen produceert, omdat dit zou vereisen dat de tool: alle dynamische content observeert die tijdens een gebruikerssessie wordt geïnjecteerd, beoordeelt of elke injectie door de gebruiker is geïnitieerd, evalueert of er een mechanisme bestaat om te sluiten of uit te stellen en of dit toegankelijk is, en bepaalt of de content kwalificeert als een noodsituatie. Dit zijn contextuele, gedragsmatige oordelen die buiten het bereik van statische DOM-analyse vallen.

• Handmatig testen vereist — Onderbrekingscontrole: Testers moeten gedurende een bepaalde tijd handmatig met de pagina interageren om te observeren of er contentupdates, meldingen, dialogen of media starten zonder gebruikersinitiatief. Voor elke waargenomen onderbreking moet de tester verifiëren dat er een toegankelijk mechanisme bestaat om deze uit te stellen of te onderdrukken, dat dit mechanisme zelf met het toetsenbord toegankelijk is en door screenreaders wordt aangekondigd, en dat de onderbreking niet opnieuw optreedt na het sluiten, tenzij de gebruiker deze opnieuw inschakelt.
• Handmatig testen vereist — Beoordeling van live-regio's: Pagina's die aria-live, role='alert' of role='status' gebruiken, moeten handmatig worden beoordeeld om te bepalen of aankondigingen worden getriggerd door gebruikersacties (acceptabel) of door tijdgebaseerde of server-pushgebeurtenissen (mogelijk niet-conform). Een geautomatiseerde tool kan de aanwezigheid van live-regio's signaleren, maar kan niet bepalen of ze onverwachte onderbrekingen veroorzaken tijdens een echte gebruikerssessie.
• Handmatig testen vereist — Gebruik van Notification API: Webapplicaties die toestemming vragen om browserniveau-pushmeldingen te versturen, moeten een duidelijk mechanisme bieden waarmee de gebruiker deze meldingen vanuit de webapplicatie zelf kan beheren of onderdrukken, en niet uitsluitend vertrouwen op browserniveau-instellingen. Dit vereist handmatige inspectie van de toestemmingsflow voor meldingen en de beschikbaarheid van in-app-meldingsvoorkeuren.

Hoe te Testen

1. Voer een geautomatiseerde scan uit als basislijn. Open de pagina in Chrome of Firefox en voer axe DevTools of Lighthouse uit. Hoewel geen van beide tools een specifieke regel voor 2.2.4 heeft, zal de geautomatiseerde scan gerelateerde problemen signaleren: ontbrekende rollen op dynamische content, onjuist geconfigureerde live-regio's en focusbeheerproblemen in dialogen. Noteer alle gemarkeerde aria-live-regio's of role='alert'-elementen, omdat deze handmatige opvolging vereisen.
2. Observeer de pagina passief gedurende minstens twee tot drie minuten. Zonder iets aan te klikken, kijk en luister naar content die verandert, verschijnt of zichzelf aankondigt. Gebruik een screenreader die op de achtergrond draait (NVDA met Firefox, of VoiceOver met Safari op macOS) en luister naar aankondigingen die niet door jouw actie zijn getriggerd. Noteer elke onderbreking, het tijdstip en de inhoud.
3. Test interactieve flows die vaak meldingen triggeren. Log in op de applicatie indien van toepassing, navigeer naar een formulier of meerstapsproces en begin dit langzaam in te vullen. Noteer alle onderbrekingen die optreden: waarschuwingen voor sessieverloop, chatuitnodigingen, promotiebanners, voortgangsupdates of abonnementsprompts. Probeer voor elke onderbreking deze te sluiten of uit te stellen met alleen het toetsenbord (Tab, Escape, Enter, Spatie). Controleer of de focus na het sluiten terugkeert naar een logische locatie.
4. Test met NVDA en Firefox. Schakel NVDA in, open Firefox en navigeer door de pagina. Luister zorgvuldig naar spraakuitvoer die je huidige lezing onderbreekt. Als een geautomatiseerde melding wordt geactiveerd, probeer deze dan met toetsenbordbediening te sluiten en controleer of NVDA de bevestiging van het sluiten aankondigt of dat de focus op de juiste manier terugkeert.
5. Test met JAWS en Chrome. Herhaal de passieve observatie en de interactieve flowtests met JAWS en Chrome. JAWS en NVDA gaan verschillend om met live-regio's, dus het is belangrijk om beide te testen om te verzekeren dat onderbrekingen consistent worden aangekondigd en dat sluitmechanismen in beide screenreaders werken.
6. Test met VoiceOver en Safari op iOS. Gebruik op een mobiel apparaat of simulator VoiceOver met Safari om door de pagina te navigeren. Veeg door de content en observeer of er onderbrekingen optreden. Test het sluitmechanisme met aanraakgebaren (dubbel tikken om te activeren) en controleer of de focus terugkeert naar een betekenisvolle locatie.
7. Controleer op een meldingsvoorkeurinstelling. Zoek naar een gebruikersprofiel, instellingenpaneel of toegankelijkheidsvoorkeurensectie binnen de applicatie. Controleer of er een instelling bestaat om meldingen globaal te onderdrukken of te configureren, en test of het inschakelen van deze instelling er daadwerkelijk voor zorgt dat onderbrekingen tijdens een volgende sessie niet meer optreden.
8. Bekijk JavaScript-broncode of netwerkactiviteit. Observeer in de browser DevTools tijdens de sessie de tabbladen Network en Console. Let op WebSocket-verbindingen, pollingintervallen of setTimeout/setInterval-aanroepen die content in de DOM injecteren. Elk hiervan is een potentiële bron van onderbrekingen en moet worden nagelopen om te verzekeren dat gebruikerscontrole is geïmplementeerd.

Hoe te Herstellen

Automatisch openende chatwidget — Onjuist

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

Automatisch openende chatwidget — Juist

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

Oncontroleerbare marketing-toastmelding — Onjuist

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

Oncontroleerbare marketing-toastmelding — Juist

<!-- 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-timeoutmodal zonder gebruikerscontrole — Onjuist

<!-- 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-timeoutmodal zonder gebruikerscontrole — Juist

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

Veelvoorkomende Fouten

• role='alert' gebruiken voor promotionele of laag-prioriteitsberichten. De rol alert signaleert urgentie aan screenreaders en veroorzaakt onmiddellijke onderbreking van het lezen. Marketingberichten, tips en functieaankondigingen moeten in plaats daarvan role='status' of aria-live='polite' gebruiken, wat content pas aankondigt nadat de screenreader zijn huidige output heeft voltooid.
• Een sluitknop bieden die alleen zichtbaar is bij hover of focus, waardoor deze praktisch ontoegankelijk is. Als het sluitmechanisme vereist dat de gebruiker met een muis zweeft om het zichtbaar te maken, kunnen toetsenbordgebruikers en screenreader-gebruikers het niet zien of bereiken. De sluitknop moet altijd zichtbaar zijn, of op zijn minst altijd bereikbaar via de Tab-volgorde van het toetsenbord.
• De focus terugzetten naar document.body na het sluiten van een melding. Wanneer een melding of dialoog wordt gesloten, moet de focus terugkeren naar een betekenisvol, contextueel passend element — meestal het element waarmee de gebruiker bezig was voordat de onderbreking verscheen. De focus op body laten vallen dwingt screenreader-gebruikers om de hele pagina opnieuw te doorlopen.
• Meerdere aria-live-regio's tegelijk activeren. Wanneer verschillende live-regio's tegelijkertijd worden bijgewerkt, plaatsen screenreaders aankondigingen in een wachtrij of laten ze deze onvoorspelbaar weg. Elke onderbreking moet zorgvuldig worden beheerd zodat slechts één live-regio tegelijk wordt geactiveerd, en updates moeten waar mogelijk worden gebundeld.
• De native toestemmingsprompt van de browser voor meldingen als voldoende gebruikerscontrole beschouwen. De toestemmingsdialoog van de browser voor de Web Notifications API werkt op OS-niveau, niet op applicatieniveau. WCAG 2.2.4 vereist dat gebruikers meldingen vanuit de webapplicatie zelf kunnen beheren, niet alleen door de site op browserniveau te blokkeren.
• Een gesloten melding bij elke paginalaadbeurt opnieuw tonen. Als een gebruiker een melding sluit en deze verschijnt opnieuw wanneer diegene terugkeert naar dezelfde pagina of een andere pagina op de site, was de sluitactie zinloos. Voorkeuren moeten ten minste voor de sessie worden bewaard met sessionStorage, of permanent met localStorage of een server-side voorkeur.
• setInterval gebruiken om roterende banners of tips te laten wisselen zonder pauzeknop. Roterende content die op een timer ververst, is een onderbreking. Als de content verandert terwijl een screenreader-gebruiker deze leest, wordt de aankondiging opnieuw gestart. Deze carrousels en roterende banners vereisen een afspeel-/pauzeknop en mogen niet onbeperkt blijven doorlopen zonder toestemming van de gebruiker.
• Een melding in de DOM injecteren op een positie die onverwachte scrollsprongen veroorzaakt. Als een meldingsbanner bovenaan de pagina wordt geïnjecteerd en de pagina naar beneden verschuift, verliezen gebruikers hun visuele leespositie. Meldingen moeten zo worden geïnjecteerd dat ze de lay-out van de content die de gebruiker momenteel bekijkt niet beïnvloeden, doorgaans met fixed of absolute positioning.
• Aannemen dat een korte automatische sluit-timer aan het criterium voldoet. Een toast die na vijf seconden verdwijnt, geeft gebruikers geen betekenisvolle controle — veel gebruikers kunnen content niet zo snel lezen, verwerken of erop reageren, vooral gebruikers met cognitieve beperkingen of gebruikers van screenreaders. Alleen een automatische sluit-timer bieden zonder een door de gebruiker bediende sluitknop is niet conform.
• Verzuimen het onderbrekingsgedrag te testen wanneer het besturingssysteem of de browser van de gebruiker voorkeuren voor verminderde beweging of meldingen heeft ingeschakeld. Sommige gebruikers stellen OS-niveauvoorkeuren in voor verminderde beweging of onderdrukte meldingen. Deze signalen moeten door de applicatie worden gerespecteerd, en ontwikkelaars moeten testen met de mediaquery prefers-reduced-motion: reduce actief om te verzekeren dat geanimeerde onderbrekingen op passende wijze worden onderdrukt.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Presidentiële Circulaire 2025/10 van Turkije, gepubliceerd in het Staatsblad (nr. 32933) op 21 juni 2025, stelt een bindend raamwerk voor webtoegankelijkheid vast voor een brede reeks organisaties die in Turkije actief zijn. De circulaire neemt WCAG 2.2 als technische referentiestandaard over en verplicht conformiteit voor de betrokken entiteiten. De entiteitstypen die expliciet door de circulaire worden bestreken, omvatten overheidsinstellingen en -agentschappen, e-commerceplatforms, banken en aanbieders van financiële diensten, ziekenhuizen en organisaties voor gezondheidsdiensten, telecommunicatiebedrijven met 200,000 of meer abonnees, erkende reisbureaus, particuliere vervoersbedrijven en particuliere scholen die opereren onder autorisatie van het Ministerie van Nationaal Onderwijs (MoNE).

WCAG 2.2.4: Interruptions is een criterium op Niveau AAA, wat betekent dat het niet behoort tot de basisconformiteitseisen onder Presidentiële Circulaire 2025/10 voor de meeste betrokken entiteiten. Organisaties die conformiteit op Niveau A en Niveau AA bereiken en verklaren, worden geacht juridisch te voldoen aan de minimumeisen van de circulaire. Toch hebben AAA-criteria zoals 2.2.4 aanzienlijk praktisch en reputatiegewicht in de Turkse marktcontext.

Verscheidene van de betrokken entiteitstypen — met name ziekenhuizen, banken en overheidsinstellingen — bedienen gebruikerspopulaties met verhoogde percentages cognitieve en neurologische aandoeningen, angststoornissen en leeftijdsgerelateerde aandachtsproblemen. Voor deze organisaties vormen ongecontroleerde onderbrekingen in digitale interfaces niet alleen een toegankelijkheidsfout, maar ook een potentieel risico op patiëntveiligheid of financiële schade. Een ziekenhuispatiëntenportaal dat onbeheersbare medicatieherinneringen of afspraakmeldingen activeert tijdens een kritische formulierinvulflow, of een bankapplicatie die niet-onderdrukbare promotiebanners toont tijdens een transactiereview, veroorzaakt reële schade voor gebruikers in deze groepen.

Voor organisaties in Turkije die leiderschap in digitale toegankelijkheid willen tonen — met name degenen die vrijwillige WCAG 2.2 Niveau AAA-verklaringen nastreven, reageren op toegankelijkheidseisen bij overheidsopdrachten, of Europese markten targeten waar de European Accessibility Act (EAA) een hogere norm stelt — is implementatie van 2.2.4 een betekenisvolle onderscheidende factor. De Accsible overlay SDK ondersteunt organisaties bij het voldoen aan deze hogere standaarden door configureerbare meldingsbeheerfuncties, het bewaren van gebruikersvoorkeuren en toegankelijkheidsbewuste widgetgedragingen te bieden die in lijn zijn met zowel de Turkse regulatoire verwachtingen als internationale best practices.