WCAG 2.2.4: Avbrott

Vad den här regeln innebär

WCAG 2.2.4: Interruptions är ett framgångskriterium på nivå AAA under Riktlinje 2.2 (Tillräckligt med tid). Det säger: "Interruptions can be postponed or suppressed by the user, except interruptions involving an emergency." I praktiska termer innebär detta att allt innehåll, alla varningar, aviseringar, dialoger eller uppdateringar som visas utan att direkt initieras av användaren måste erbjuda användaren en mekanism för att skjuta upp eller inaktivera dem — såvida inte avbrottet kommunicerar en verklig nödsituation, såsom ett brandlarm, ett livshotande medicinskt larm eller ett kritiskt systemfel.

Ett avbrott, i WCAG-bemärkelse, är varje händelse som inträffar oberoende av användarens aktuella handling och avleder uppmärksamheten från det användaren håller på med. Detta inkluderar men är inte begränsat till: toast-aviseringar, push-notiser, chattwidgetar som öppnas automatiskt, statusbanderoller som uppdateras eller ändras, automatiskt uppspelande media, live region-annonseringar som injiceras av JavaScript, modala dialoger som triggas av en timer och cookie-samtyckesbanderoller som dyker upp mitt i en session. Kriteriet förbjuder inte dessa mönster i sig; det kräver att användare ges kontroll över dem.

En sida klarar 2.2.4 när varje icke-akut avbrott har minst ett av följande: en användartillgänglig inställning som inaktiverar avbrottet innan det inträffar, en mekanism i själva avbrottet för att avvisa eller skjuta upp det, eller en global webbplatsnivåinställning som helt undertrycker sådana avbrott. En sida underkänns när avbrott visas automatiskt, inte erbjuder någon mekanism för att avvisa eller skjuta upp dem och inte är relaterade till en nödsituation. Till exempel skulle en livechattbubbla som expanderar automatiskt efter 10 sekunder utan stängknapp, eller en aviseringsbanderoll som cyklar genom marknadsföringsmeddelanden och inte kan stoppas, båda underkännas.

Det enda uttryckligen definierade undantaget är nödsituationer. Om innehåll måste avbryta användaren för att kommunicera fara för hälsa, säkerhet eller liv — till exempel en sjukhusportal som skickar ett kritiskt medicinlarm — får det avbrottet åsidosätta användarens preferenser. Detta undantag är avsiktligt snävt; rutinmässiga marknadsföringsmeddelanden, varningar om sessionstimeout med gott om tid kvar och lågprioriterade statusuppdateringar kvalificerar inte som nödsituationer.

Eftersom WCAG 2.2.4 är nivå AAA krävs det inte för grundläggande överensstämmelsekrav, men det är en meningsfull standard för organisationer som är engagerade i full inkludering. Det gäller allt webbinnehåll: skrivbords- och mobilwebbapplikationer, single-page-applikationer som använder JavaScript-drivna aviseringar och progressiva webbappar som utnyttjar Web Notifications API.

Varför det är viktigt

Oväntade avbrott på en webbsida är inte bara irriterande — för många användare utgör de ett allvarligt hinder för att slutföra uppgifter och, i vissa fall, en direkt hälsorisk.

Användare med kognitiva funktionsnedsättningar och uppmärksamhetsrelaterade funktionsnedsättningar — inklusive ADHD, traumatisk hjärnskada, autismspektrumtillstånd och demens — är i hög grad beroende av en stabil, förutsägbar miljö för att bibehålla fokus. En plötslig avisering eller animerad varning kan helt bryta deras koncentration och göra att de tappar bort sig i en flerstegsprocess, såsom att slutföra en ansökan om förmåner, granska en journal eller fylla i en deklarationsblankett. Att orientera sig igen efter ett avbrott kan ta avsevärt längre tid för dessa användare än för neurotypiska användare, och i vissa fall kanske de inte kan hitta tillbaka alls.

Skärmläsaranvändare påverkas särskilt av dynamiska avbrott. När en live region eller ARIA-varning injiceras i DOM:en är skärmläsare som NVDA, JAWS och VoiceOver utformade för att omedelbart annonsera den, vilket avbryter det som hjälpmedelstekniken för närvarande läser upp. Om en användare lyssnar på ett långt stycke med viktiga instruktioner och en marknadsföringstoast triggas mitt i en mening, överger skärmläsaren stycket och annonserar aviseringen. Användaren måste sedan navigera tillbaka, hitta sin plats och läsa om — en process som är betydligt mer betungande än det låter för någon som navigerar enbart med tangentbord och ljud.

Användare med ångestsyndrom och PTSD kan uppleva fysiska stressreaktioner — förhöjd puls, koncentrationssvårigheter eller panik — som triggas av plötsliga, oväntade visuella eller auditiva förändringar. Oförutsägbarheten i en okontrollerad avbrottsmiljö kan göra vissa webbplatser i praktiken oanvändbara för dessa grupper.

Användare med epilepsi eller vestibulära störningar kan skadas av vissa typer av avbrott, särskilt sådana som involverar blinkningar eller snabba rörelser. Även om Riktlinje 2.3 specifikt behandlar anfallsrisker, korsar animerade aviseringsbanderoller och automatiskt uppspelade videoaviseringar som dyker upp oväntat båda kriterierna.

Överväg ett konkret scenario: en användare med ADHD använder en internetbankportal för att föra över pengar mellan konton. Hen granskar noggrant överföringsbeloppet och mottagarkontots nummer. En kampanjerbjudande-avisering glider in från nedre högra hörnet, triggar en skärmläsarannonsering och en animerad inmatning. Användaren tappar bort sig, kan inte hitta stängknappen eftersom animationen har dragit fokus bort och skickar av misstag fel belopp. Detta är inte ett hypotetiskt extremfall — det är ett förutsägbart resultat av att ignorera detta kriterium.

Utöver funktionsnedsättning skadar okontrollerade avbrott också användbarheten för alla användare, ökar avvisningsfrekvensen (användare lämnar helt enkelt webbplatser som bombarderar dem) och kan minska konverteringen för just de åtgärder som avbrotten var avsedda att främja. Ur ett SEO-perspektiv är höga avvisningsfrekvenser och korta sessionstider korrelerade med sämre signaler för sökrankning, vilket innebär att tillgänglighet och affärsprestanda är i linje här.

Relaterade Axe-core-regler

WCAG 2.2.4 kräver manuell testning. Automatiserade verktyg, inklusive axe-core, kan inte på ett tillförlitligt sätt upptäcka om en webbplats producerar okontrollerbara avbrott, eftersom det skulle kräva att verktyget: observerar allt dynamiskt innehåll som injiceras under en användarsession, bedömer om varje injektion initierades av användaren, utvärderar om en mekanism för att avvisa eller skjuta upp finns och är tillgänglig samt avgör om innehållet kvalificerar som en nödsituation. Detta är kontextuella, beteendemässiga bedömningar som ligger utanför räckvidden för statisk DOM-analys.

• Manuell testning krävs — Kontroll av avbrott: Testare måste manuellt interagera med sidan under en tidsperiod för att observera om något innehåll uppdateras, visas eller startar media utan användarinitiering. För varje observerat avbrott måste testaren verifiera att det finns en tillgänglig mekanism för att skjuta upp eller undertrycka det, att denna mekanism i sig är tangentbordsåtkomlig och annonseras av skärmläsare, och att avbrottet inte återkommer efter avvisning utan att användaren återaktiverar det.
• Manuell testning krävs — Bedömning av live region: Sidor som använder aria-live, role='alert' eller role='status' måste granskas manuellt för att avgöra om annonseringar triggas av användaråtgärder (acceptabelt) eller av tidsbaserade eller serverpush-händelser (potentiellt icke-kompatibelt). Ett automatiserat verktyg kan flagga förekomsten av live regioner men kan inte avgöra om de producerar oväntade avbrott under en verklig användarsession.
• Manuell testning krävs — Användning av Notification API: Webbapplikationer som begär tillstånd att skicka push-notiser på webbläsarnivå måste erbjuda en tydlig mekanism för användaren att hantera eller undertrycka dessa aviseringar inifrån själva webbapplikationen, inte enbart förlita sig på kontroller på webbläsarnivå. Detta kräver manuell granskning av flödet för aviseringstillstånd och tillgången till aviseringar i appens inställningar.

Hur man testar

1. Kör en automatiserad skanning som baslinje. Öppna sidan i Chrome eller Firefox och kör axe DevTools eller Lighthouse. Även om inget av verktygen har en dedikerad regel för 2.2.4, kommer den automatiserade skanningen att flagga relaterade problem: saknade roller på dynamiskt innehåll, felkonfigurerade live regioner och fokusproblem i dialoger. Notera alla aria-live-regioner eller role='alert'-element som flaggas, eftersom dessa kräver manuell uppföljning.
2. Observera sidan passivt i minst två till tre minuter. Utan att klicka på något, titta och lyssna efter allt innehåll som ändras, visas eller annonserar sig självt. Använd en skärmläsare som körs i bakgrunden (NVDA med Firefox eller VoiceOver med Safari på macOS) och lyssna efter alla annonseringar som inte triggades av din handling. Notera varje avbrott, dess timing och dess innehåll.
3. Testa interaktiva flöden som vanligtvis triggar aviseringar. Logga in i applikationen om tillämpligt, navigera till ett formulär eller en flerstegsprocess och börja fylla i den långsamt. Notera alla avbrott som inträffar: varningar om sessionstimeout, chattinbjudningar, kampanjbanderoller, statusuppdateringar eller prenumerationsuppmaningar. För varje, försök att avvisa eller skjuta upp det med enbart tangentbordet (Tab, Escape, Enter, Space). Verifiera att fokus återgår till en logisk plats efter avvisning.
4. Testa med NVDA och Firefox. Aktivera NVDA, öppna Firefox och navigera på sidan. Lyssna noggrant efter all talutmatning som avbryter din aktuella uppläsning. Om en automatisk avisering triggas, försök att avvisa den med tangentbordskontroller och verifiera att NVDA annonserar bekräftelsen på avvisningen eller att fokus återgår på ett lämpligt sätt.
5. Testa med JAWS och Chrome. Upprepa de passiva observations- och interaktiva flödestesterna med JAWS och Chrome. JAWS och NVDA hanterar live regioner olika, så det är viktigt att testa båda för att säkerställa att avbrott annonseras konsekvent och att avvisningsmekanismer fungerar i båda skärmläsarna.
6. Testa med VoiceOver och Safari på iOS. På en mobil enhet eller simulator, använd VoiceOver med Safari för att navigera på sidan. Svep genom innehållet och observera om några avbrott inträffar. Testa avvisningsmekanismen med touchgester (dubbeltryck för att aktivera) och verifiera att fokus återgår till en meningsfull plats.
7. Kontrollera om det finns en inställning för aviseringar. Leta efter en användarprofil, en inställningspanel eller en sektion för tillgänglighetspreferenser i applikationen. Verifiera att det finns en kontroll för att globalt undertrycka eller konfigurera aviseringar, och testa att aktivering av denna inställning faktiskt förhindrar avbrott från att inträffa under en efterföljande session.
8. Granska JavaScript-källkod eller nätverksaktivitet. I webbläsarens DevTools, observera flikarna Network och Console under sessionen. Leta efter WebSocket-anslutningar, pollingintervall eller setTimeout/setInterval-anrop som injicerar innehåll i DOM:en. Var och en av dessa är en potentiell källa till avbrott och bör spåras för att säkerställa att användarkontroll är implementerad.

Hur man åtgärdar

Automatiskt öppnande chattwidget — Felaktigt

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

Automatiskt öppnande chattwidget — Korrekt

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

Okontrollerbar marknadsföringstoast — Felaktigt

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

Okontrollerbar marknadsföringstoast — Korrekt

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

Sessionstimeout-modal utan användarkontroll — Felaktigt

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

Sessionstimeout-modal utan användarkontroll — Korrekt

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

Vanliga misstag

• Att använda role='alert' för marknadsförings- eller lågprioriterade meddelanden. Rollen alert signalerar brådska till skärmläsare och orsakar omedelbart avbrott i uppläsningen. Marknadsföringsmeddelanden, tips och funktionsannonseringar bör istället använda role='status' eller aria-live='polite', vilket annonserar innehåll först efter att skärmläsaren har avslutat sin aktuella utmatning.
• Att tillhandahålla en stängknapp som bara är synlig vid hovring eller fokus, vilket gör den praktiskt taget otillgänglig. Om avvisningsmekanismen kräver att användaren hovrar med musen för att visa den kan tangentbordsanvändare och skärmläsaranvändare inte se eller nå den. Stängknappen måste alltid vara synlig, eller åtminstone alltid nåbar via tangentbordets Tab-ordning.
• Att återställa fokus till document.body efter att en avisering avvisats. När en avisering eller dialog avvisas måste fokus återgå till ett meningsfullt, kontextuellt lämpligt element — vanligtvis det element som användaren interagerade med innan avbrottet inträffade. Att släppa fokus på body tvingar skärmläsaranvändare att åter-navigera hela sidan.
• Att trigga flera aria-live-regioner samtidigt. När flera live regioner uppdateras samtidigt köar eller tappar skärmläsare annonseringar på ett oförutsägbart sätt. Varje avbrott bör hanteras noggrant så att endast en live region triggas åt gången, och uppdateringar bör grupperas där det är möjligt.
• Att betrakta webbläsarens inbyggda dialog för aviseringstillstånd som tillräcklig användarkontroll. Webbläsarens tillståndsdialog för Web Notifications API fungerar på OS-nivå, inte applikationsnivå. WCAG 2.2.4 kräver att användare kan hantera aviseringar inifrån själva webbapplikationen, inte bara genom att blockera webbplatsen på webbläsarnivå.
• Att återställa en avvisad avisering vid varje sidladdning. Om en användare avvisar en avisering och den dyker upp igen nästa gång hen navigerar till samma sida eller en annan sida på webbplatsen, var avvisningsåtgärden meningslös. Preferenser bör bestå åtminstone under sessionen med sessionStorage, eller permanent med localStorage eller en serverbaserad preferens.
• Att använda setInterval för att cykla genom roterande banderoller eller tips utan en pauskontroll. Roterande innehåll som uppdateras med en timer är ett avbrott. Om innehållet ändras medan en skärmläsaranvändare läser det, startar annonseringen om. Dessa karuseller och roterande banderoller kräver en spela/paus-kontroll och får inte loopa i all oändlighet utan användarens samtycke.
• Att injicera en avisering i DOM:en på en position som orsakar oväntade rullningshopp. Om en aviseringsbanderoll injiceras högst upp på sidan och sidan flyttas nedåt tappar användare sin visuella läsposition. Aviseringar bör injiceras på ett sätt som inte påverkar layouten av det innehåll användaren för närvarande tittar på, vanligtvis med fixed eller absolute positioning.
• Att anta att en kort automatisk stängningstimer uppfyller kriteriet. En toast som försvinner efter fem sekunder ger inte användare meningsfull kontroll — många användare kan inte läsa, bearbeta eller reagera på innehåll så snabbt, särskilt de med kognitiva funktionsnedsättningar eller de som använder skärmläsare. Att endast tillhandahålla en automatisk stängningstimer utan en användarkontrollerad stängknapp är icke-kompatibelt.
• Att inte testa avbrottsbeteende när användarens operativsystem eller webbläsare har inställningar för minskad rörelse eller aviseringar aktiverade. Vissa användare ställer in OS-nivåpreferenser för minskad rörelse eller undertryckta aviseringar. Dessa signaler bör respekteras av applikationen, och utvecklare bör testa med media queryn prefers-reduced-motion: reduce aktiv för att säkerställa att animerade avbrott undertrycks på ett lämpligt sätt.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentcirkulär 2025/10, publicerat i den officiella tidningen (nr 32933) den 21 juni 2025, etablerar ett bindande ramverk för webbtillgänglighet för ett brett spektrum av organisationer som är verksamma i Turkiet. Cirkuläret antar WCAG 2.2 som sin tekniska referensstandard och föreskriver överensstämmelse för berörda aktörer. De aktörstyper som uttryckligen omfattas av cirkuläret inkluderar offentliga institutioner och myndigheter, e-handelsplattformar, banker och finansiella tjänsteleverantörer, sjukhus och hälso- och sjukvårdsorganisationer, telekommunikationsföretag med 200,000 eller fler abonnenter, licensierade resebyråer, privata transportföretag och privatskolor som verkar med tillstånd från Ministry of National Education (MoNE).

WCAG 2.2.4: Interruptions är ett kriterium på nivå AAA, vilket innebär att det inte ingår bland de grundläggande överensstämmelsekraven enligt presidentcirkulär 2025/10 för de flesta berörda aktörer. Organisationer som uppnår och deklarerar överensstämmelse på nivå A och nivå AA anses juridiskt följa cirkulärets minimikrav. Kriterier på nivå AAA, såsom 2.2.4, har dock betydande praktisk och reputationsmässig tyngd i den turkiska marknadskontexten.

Flera av de berörda aktörstyperna — särskilt sjukhus, banker och offentliga institutioner — betjänar användargrupper med förhöjda nivåer av kognitiva och neurologiska tillstånd, ångestsyndrom och åldersrelaterade uppmärksamhetssvårigheter. För dessa organisationer utgör okontrollerade avbrott i digitala gränssnitt inte bara ett tillgänglighetsmisslyckande utan också en potentiell risk för patientsäkerhet eller finansiell skada. En patientportal på ett sjukhus som triggar okontrollerbara medicinpåminnelser eller aviserar om bokningar under ett kritiskt formulärflöde, eller en bankapplikation som visar icke-undertryckbara kampanjbanderoller under en transaktionsgranskning, skapar reella skador för användare i dessa grupper.

För organisationer i Turkiet som vill visa ledarskap inom digital tillgänglighet — särskilt de som strävar efter frivilliga deklarationer om WCAG 2.2 nivå AAA, svarar på krav på tillgänglighet i offentlig upphandling eller riktar sig mot europeiska marknader där European Accessibility Act (EAA) ställer högre krav — är implementering av 2.2.4 en meningsfull differentieringsfaktor. Accsible overlay SDK stödjer organisationer i att uppfylla dessa högre standarder genom att tillhandahålla konfigurerbara funktioner för hantering av aviseringar, beständighet för användarpreferenser och tillgänglighetsmedvetna widgetbeteenden som ligger i linje med både turkiska regulatoriska förväntningar och internationell bästa praxis.