WCAG 2.3.2: Tre blink

Vad den här regeln innebär

WCAG 2.3.2 Tre blixtar är ett framgångskriterium på nivå AAA under principen Hanterbar. Det anger att webbsidor inte får innehålla något som blinkar mer än tre gånger under någon enskild tidsperiod på en sekund. Till skillnad från motsvarigheten på nivå AA (2.3.1 Tre blixtar eller under tröskelvärdet) tillåter detta kriterium inga undantag för små blinkande områden eller blinkningar som ligger under den allmänna blixt- och röd-blixt-tröskeln. Regeln är absolut: om innehåll blinkar mer än tre gånger per sekund är det ett fel, oavsett storlek, färg eller kontrast.

En blixt definieras av WCAG som ett par motsatta förändringar i relativ luminans som kan orsaka anfall hos vissa personer. Mer praktiskt omfattar detta all synlig på–av-blinkning, stroboskopliknande animation, snabbt växlande bilder eller flimrande video som genomför mer än tre fullständiga cykler per sekund. Termen ”tre blixtar” syftar på tre fullständiga oscillationer — vilket innebär innehåll som växlar mellan ett ljusare och ett mörkare tillstånd tre gånger inom en enda sekund.

De berörda innehållstyperna är många och inkluderar animerade GIF:ar, CSS-animationer som använder @keyframes, JavaScript-styrda DOM-uppdateringar som orsakar snabb visuell växling, HTML5 Canvas-animationer, inbäddat videoinnehåll, SVG-animationer och tredjeparts annonsnätverk eller widgets som bäddar in animerade medier. Även subtilt flimmer i rullande löptext (marquee) eller snabbt uppdaterade datavisualiseringar kan utlösa detta kriterium om frekvensen överstiger tre blixtar per sekund.

Ett godkänt resultat enligt 2.3.2 innebär att sidan inte innehåller något blinkande innehåll alls som överstiger tröskeln tre blixtar per sekund. Ett underkänt resultat uppstår när någon del av sidan — oavsett hur litet området är — blinkar mer än tre gånger inom ett tidsfönster på en sekund. Det finns inget undantag för ”säkra områden” i detta kriterium, vilket är det som skiljer det från 2.3.1. En liten blinkande markör, en animerad laddningsindikator eller en snabbt växlande annonsbanner kan alla utgöra fel om de blinkar med frekvenser över 3 Hz.

Varför det är viktigt

Fotosensitiv epilepsi påverkar ungefär 1 av 4 000 personer globalt, men den totala populationen som är mottaglig för någon form av fotosensitiv neurologisk reaktion — inklusive fotosensitiva migräner, vestibulära störningar och icke-epileptisk fotosensitivitet — är avsevärt större. För dessa personer är exponering för snabbt blinkande innehåll på en skärm inte bara en irritation: det kan utlösa grand mal-anfall, medvetslöshet, skador eller i sällsynta fall dödsfall. Till skillnad från många tillgänglighetshinder som försämrar användarupplevelsen utgör blinkande innehåll en akut säkerhetsrisk.

Föreställ dig ett praktiskt scenario: en turkisk nyhetssajt bäddar in en live-ticker med en animerad markeringseffekt som pulserar med 8 Hz för att dra uppmärksamhet till senaste nytt. En användare med fotosensitiv epilepsi öppnar sidan på sin telefon under pendlingen. Inom några sekunder utlöser det snabba flimret ett fokalt anfall, vilket gör att personen tappar telefonen och tillfälligt förlorar muskelkontrollen. De hade ingen varning, inget sätt att inaktivera effekten i förväg och ingen möjlighet att agera. Detta scenario är helt förebyggbart genom att begränsa blinkfrekvensen till tre per sekund eller färre — eller genom att eliminera blinkande innehåll helt, vilket 2.3.2 kräver.

Utöver den neurologiska säkerhetsdimensionen gynnar efterlevnad av detta kriterium också användare med vestibulära störningar (som upplever yrsel, illamående eller desorientering av rörelse), användare med migrän som utlöses av visuella mönster och användare med uppmärksamhetsstörningar som upplever snabbt blinkande innehåll som omöjligt att ignorera eller komma runt. Att minska eller eliminera blinkande innehåll tenderar också att förbättra upplevd sidprofessionalism och minska avhoppsfrekvensen, eftersom många användare — funktionsnedsatta eller inte — upplever aggressiva animationer som irriterande.

Ur ett SEO- och prestandaperspektiv minskar eliminering av tunga animationer och snabba CSS-övergångar CPU- och GPU-belastningen, vilket förbättrar Core Web Vitals-värden som Total Blocking Time och Cumulative Layout Shift, som båda är ranking-signaler hos Google.

Relaterade Axe-core-regler

WCAG 2.3.2 kräver manuell testning. Ingen automatiserad axe-core-regel motsvarar direkt detta kriterium, och detta är avsiktligt — här är varför automatiska verktyg inte pålitligt kan upptäcka överträdelser:

• Manuell testning krävs — Detektering av blinkfrekvens: Automatiska tillgänglighetsskannrar inspekterar den statiska DOM:en och CSS vid en enda tidpunkt. De kan inte observera hur innehåll beter sig under en hel sekund av uppspelad animation, mäta luminansoscillationsfrekvensen i en video eller animerad GIF, eller utvärdera bildfrekvensen i en Canvas-animation. Blinkfrekvensen är en tidsberoende egenskap som kräver observation i realtid, vilket gör den i grunden bortom räckhåll för statiska analysverktyg som axe-core. En mänsklig testare — eller specialiserade fotosensitivitetsanalysverktyg som Photosensitive Epilepsy Analysis Tool (PEAT) — måste granska animerat innehåll i rörelse för att avgöra om det överstiger tröskeln tre blixtar per sekund.
• Manuell testning krävs — Tredjeparts- och inbäddat innehåll: Annonser, inbäddade videor, sociala medie-widgets och iframes kan injicera animerat innehåll som axe-core inte kan analysera, eftersom det verkar inom webbläsarens same origin-policy. En testare måste manuellt observera allt inbäddat och tredjepartsinnehåll under uppspelning för att bedöma efterlevnad.
• Manuell testning krävs — JavaScript-styrda animationer: Snabb växling av CSS-klasser, uppdatering av canvas-pixlar eller manipulering av SVG-element via JavaScript med hög frekvens kan skapa blinkeffekter som är osynliga i en statisk DOM-ögonblicksbild. Testare måste köra sidan i en live-webbläsare, observera alla animerade tillstånd och tidsmäta blinkcyklerna manuellt eller med bildfrekvensanalysverktyg.

Hur man testar

1. Kör en automatisk skanning som baslinje: Använd axe DevTools, Lighthouse eller Accsible-widgetens inbyggda granskning för att identifiera eventuella flaggade animationsrelaterade problem. Även om ingen regel direkt motsvarar 2.3.2 kan dessa verktyg lyfta fram relaterade varningar om CSS-animationer eller ARIA live regions som uppdateras snabbt. Notera alla flaggade punkter, men förstå att en ren automatisk rapport inte bekräftar efterlevnad av 2.3.2.
2. Identifiera allt animerat innehåll manuellt: Ladda sidan i en webbläsare och observera den i minst 30 sekunder utan att interagera. Notera varje element som blinkar, flammar, animeras eller ändrar visuellt tillstånd upprepade gånger. Inkludera laddningsindikatorer, banners, hero-animationer, automatiskt uppspelade videor, animerade bakgrunder och alla tredjeparts-widgets. Skapa en inventering av dessa element.
3. Använd Photosensitive Epilepsy Analysis Tool (PEAT): För videoinnehåll eller skärminspelningar av animationer, använd PEAT (ett kostnadsfritt verktyg från Trace Research and Development Center) för att analysera materialet bildruta för bildruta. PEAT flaggar alla sekvenser som överstiger blixttrösklarna och rapporterar både den allmänna blixttröskeln och den röda blixttröskeln. Ett fel enligt 2.3.2 är varje blixt som överstiger tre per sekund oavsett andra tröskelvärden.
4. Mät CSS- och JavaScript-animationshastigheter: Öppna webbläsarens DevTools (Chrome eller Firefox) och använd fliken Performance för att spela in en 5-sekunderssession medan animationer spelas. Inspektera flame graph för snabbt upprepade paint- eller layoutoperationer. Du kan också öppna panelen Animations i Chrome DevTools för att se pågående animationer och deras varaktighet — dela 1000 ms med animationens varaktighet för att beräkna Hz.
5. Testa med NVDA + Firefox, VoiceOver + Safari och JAWS + Chrome: Skärmläsaranvändare är inte undantagna från fotosensitivitet. Starta varje skärmläsare och navigera till sidan på vanligt sätt. Om något innehåll som blinkar visuellt också presenteras på ett sätt som orsakar snabba skärmuppdateringar (till exempel en live region som annonserar varje bildruta i en räknare), dokumentera detta. Visuellt blinkande är fortfarande en överträdelse även för skärmläsaranvändare eftersom de kan ha viss funktionell syn.
6. Verifiera tredjeparts- och inbäddat innehåll: Skrolla igenom alla iframes, inbäddade inlägg från sociala medier, annonsytor och videospelare. Spela manuellt upp alla videor där autoplay är inaktiverat och observera om det förekommer snabbt flimmer. Kontrollera animerade GIF:ar genom att högerklicka och inspektera bildrutedata i ett bildredigeringsprogram eller i webbläsarens Network-flik för att uppskatta bildfrekvensen.
7. Upprepa testning på olika enheter och webbläsare: Vissa animationer körs i olika hastigheter på mobil jämfört med desktop på grund av skillnader i hårdvaruacceleration. Testa både i en desktop-webbläsare och på en mobil enhet (iOS Safari och Android Chrome) för att bekräfta konsekvent efterlevnad.

Hur man åtgärdar

CSS keyframe-animation som blinkar för snabbt — Felaktig

<!-- A badge that flashes to draw attention, completing 8 cycles per second -->
<style>
  @keyframes flash-badge {
    0%, 49% { background-color: red; }
    50%, 100% { background-color: transparent; }
  }
  .alert-badge {
    animation: flash-badge 0.125s infinite; /* 8 Hz — far exceeds 3 per second */
  }
</style>
<span class='alert-badge'>NEW</span>

CSS keyframe-animation som blinkar för snabbt — Korrekt

<!-- Animation slowed to complete fewer than 3 cycles per second -->
<style>
  @keyframes flash-badge {
    0%, 49% { background-color: red; }
    50%, 100% { background-color: transparent; }
  }
  .alert-badge {
    animation: flash-badge 0.4s infinite; /* ~2.5 Hz — safely below the 3 Hz threshold */
  }
</style>
<span class='alert-badge'>NEW</span>
<!-- Better still: remove the animation entirely and use a static high-contrast badge -->

JavaScript DOM-växling som orsakar snabbt flimmer — Felaktig

<!-- Script toggles visibility 10 times per second to simulate a strobe effect -->
<div id='strobe-element' style='width:200px;height:200px;background:white;'></div>
<script>
  setInterval(function() {
    var el = document.getElementById('strobe-element');
    el.style.background = el.style.background === 'white' ? 'black' : 'white';
  }, 100); /* Fires every 100ms = 10 flashes per second -- a serious seizure risk */
</script>

JavaScript DOM-växling som orsakar snabbt flimmer — Korrekt

<!-- Removed the rapid toggle entirely; convey state change through text or icon instead -->
<div id='status-element' style='width:200px;height:200px;background:#005fcc;'>
  <p style='color:white;padding:1rem;'>System Active</p>
</div>
<!-- If animation is genuinely needed, keep it well under 3 Hz and prefer opacity/color
     transitions over high-contrast luminance switches -->

Animerad GIF med hög bildfrekvens — Felaktig

<!-- An animated GIF advertisement that cycles through frames at 10 fps -->
<img src='promo-flash.gif' alt='Special offer — 50% off this weekend only'>
<!-- The GIF's internal frame delay is set to 10ms per frame, creating rapid flicker -->

Animerad GIF med hög bildfrekvens — Korrekt

<!-- Replace the animated GIF with a static image, or re-export the GIF
     with a minimum frame delay of 334ms per frame (3 fps or slower) -->
<img src='promo-static.png' alt='Special offer — 50% off this weekend only'>
<!-- If motion must be preserved, use a CSS animation with prefers-reduced-motion support -->
<picture>
  <source srcset='promo-static.png' media='(prefers-reduced-motion: reduce)'>
  <img src='promo-slow.gif' alt='Special offer — 50% off this weekend only'>
</picture>

Vanliga misstag

• Att anta att undantaget för ”litet område” från 2.3.1 gäller för 2.3.2: WCAG 2.3.1 tillåter blinkande innehåll som upptar mindre än 25% av ett visuellt fält på 10 grader. WCAG 2.3.2 har inget sådant undantag — en liten blinkande markör eller en liten laddningspunkt som blinkar mer än tre gånger per sekund är en fullständig överträdelse på AAA-nivå.
• Att sätta CSS animation-duration till värden som 0.1s eller 0.2s utan att beräkna den resulterande blinkfrekvensen: En 0.1s-animation som oscillerar mellan två tillstånd genomför 10 cykler per sekund (10 Hz). Dela 1 med varaktigheten i sekunder för att få Hz; säkerställ att resultatet är 3 eller lägre.
• Att bädda in tredjeparts annons-skript utan att granska animationsbeteendet: Annonsnätverk levererar ofta animerade annonser med hög blinkfrekvens optimerade för klickfrekvens, inte tillgänglighet. Granska alltid tredjepartsinnehåll med PEAT eller manuell bildruteinspektion innan driftsättning.
• Att använda setInterval eller requestAnimationFrame-loopar för att snabbt växla CSS-klasser för laddnings- eller progressindikatorer: Varje JavaScript-loop som ändrar ett elements luminans eller synlighet mer än tre gånger per sekund skapar en överträdelse av 2.3.2, även om effekten ser subtil ut under normala visningsförhållanden.
• Att inte testa animerade SVG- och Canvas-element: SVG-animationer som använder <animate> eller SMIL, och Canvas-baserade spel eller datavisualiseringar, testas sällan med PEAT eller bildfrekvensverktyg, men de kan fullt ut överskrida blixttröskeln.
• Att enbart förlita sig på axe-core eller Lighthouse för att bekräfta efterlevnad av 2.3.2: Automatiska verktyg kan inte upptäcka detta kriterium. En ren automatisk skanningsrapport betyder ingenting för 2.3.2; endast manuell granskning och PEAT-analys kan bekräfta efterlevnad.
• Att behandla prefers-reduced-motion som en fullständig lösning för 2.3.2: Att respektera media queryn prefers-reduced-motion är en god praxis och hjälpsamt för många användare, men det är en mekanism som kräver att användaren aktivt väljer in. WCAG 2.3.2 kräver att innehåll är säkert som standard, inte bara när användaren har ställt in en systempreferens. Användare som inte har konfigurerat denna inställning förblir utsatta.
• Att endast tillämpa begränsningar för blinkfrekvens på video men inte på CSS-, JavaScript- eller GIF-animationer: Team granskar ibland videoinnehåll med PEAT men förbiser CSS keyframe-animationer och JavaScript-styrda växlingar. Alla animationstekniker måste utvärderas.
• Att använda background-image i CSS för att visa animerade GIF:ar: Animerade GIF:ar som sätts som CSS-bakgrundsbilder är mindre synliga för testare som gör en visuell genomgång och är lätta att förbise under granskningar. Inkludera alltid bakgrundsbilder i din animationsinventering.
• Att inte testa på nytt efter att A/B-testning eller personaliseringsändringar injicerar nytt animerat innehåll: Marknadsförings- och personaliseringssystem kan dynamiskt injicera banners eller överlägg med animationer som aldrig granskats för efterlevnad av WCAG 2.3.2. Etablera en granskningsprocess för allt dynamiskt injicerat innehåll.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentdekret 2025/10, publicerat i Officiella tidningen nr 32933 den 21 juni 2025, fastställer obligatoriska tillgänglighetsstandarder för webb och mobil för ett brett spektrum av aktörer verksamma i Turkiet. Cirkuläret antar WCAG 2.2 som sin tekniska referensram, med obligatorisk efterlevnad som generellt krävs på nivå A och nivå AA.

WCAG 2.3.2 är ett kriterium på nivå AAA och är därför inte juridiskt obligatoriskt enligt cirkuläret för de flesta berörda aktörer. Dess ämnesområde — att förhindra innehåll som kan utlösa anfall — sammanfaller dock direkt med den allmänna omsorgsplikten och icke-diskrimineringsprinciperna som ligger till grund för regleringen. Följande aktörstyper omfattas av cirkuläret och bör behandla 2.3.2 som en stark bästa praxis-skyldighet även där det inte strikt krävs: e-handelsplattformar, offentliga institutioner och statliga myndigheter, banker och finansiella institutioner, sjukhus och vårdgivare, telekommunikationsföretag med 200 000 eller fler abonnenter, resebyråer, privata transportföretag och privatskolor auktoriserade av Ministry of National Education (MoNE).

För särskilt offentliga institutioner och vårdgivare är de etiska insatserna kring 2.3.2 särskilt höga. En statlig hälsoportal eller en sjukhussida med patientinformation som utlöser ett anfall hos en fotosensitiv besökare skulle utgöra både ett säkerhetsmisslyckande och en förtroendekris. Även om cirkuläret inte uttryckligen kräver efterlevnad på AAA-nivå bör organisationer som vill uppvisa tillgänglighet i toppklass — vare sig för upphandlingskvalificering, allmänhetens förtroende eller internationella affärspartnerskap — implementera 2.3.2 tillsammans med sina obligatoriska A- och AA-åtaganden.

Organisationer som tillhandahåller tjänster till EU-marknaden bör också notera att European Accessibility Act (EAA), som började tillämpas i juni 2025, hänvisar till EN 301 549, som i sin tur hänvisar till WCAG. Turkiska företag som exporterar digitala produkter eller tjänster till EU-medlemsstater kan möta striktare krav via den kanalen. Att implementera 2.3.2 proaktivt positionerar turkiska organisationer väl för både inhemsk och gränsöverskridande efterlevnad.

Ur ett praktiskt genomförandeperspektiv kan Accsible overlay widget SDK hjälpa berörda organisationer genom att ge användare möjlighet att pausa eller stoppa alla animationer på en sida, vilket bidrar till att minska fotosensitivitetsrisk för användare som är medvetna om sin åkomma. Denna användarinitierade kontroll är dock en kompletterande åtgärd, inte en ersättning för att ta bort eller sakta ner blinkande innehåll vid källan, vilket 2.3.2 kräver.