WCAG 2.3.1: Tre blinkningar eller under tröskelvärdet

Vad den här regeln innebär

WCAG 2.3.1 — Tre blixtar eller under tröskelvärdet — är ett framgångskriterium på nivå A under principen Hanterbar. Den kräver att webbsidor inte får innehålla något innehåll som blinkar mer än tre gånger under någon enskild sekund, om inte det blinkande innehållet är tillräckligt litet eller tillräckligt svagt för att hamna under det definierade allmänna blixttröskelvärdet eller rött-blixt-tröskelvärdet.

En blixt definieras som ett par motsatta förändringar i relativ luminans som kan orsaka anfall hos känsliga individer. Mer specifikt definierar WCAG två typer av farliga blixtar:

• Allmän blixt: Ett par motsatta förändringar där den högre luminansen är minst 10% av den maximala relativa luminansen (0,80), och luminansskillnaden är minst 10% av det maximala värdet. I praktiken innebär detta innehåll som växlar mellan ett ljust och ett mörkt tillstånd tillräckligt snabbt för att skapa en stroboskopisk effekt.
• Röd blixt: Ett par motsatta övergångar som involverar en mättad röd färg. Detta behandlas med särskild försiktighet eftersom röda blixtar kliniskt har kopplats till en högre risk att utlösa ljuskänsliga anfall.

Kriteriet gäller allt webbinnehåll oavsett format — HTML-animationer, CSS-övergångar, JavaScript-styrda effekter, inbäddade videor, GIF:ar, SVG-animationer, WebGL-scener, canvas-renderad grafik och tredjepartsannonseringswidgets. Om innehåll blinkar med en frekvens som överstiger tre blixtar per sekund och inte hamnar under tröskelvärdena för luminans eller storlek, underkänns det ovillkorligen enligt detta kriterium.

Undantag och tröskelvärden som gör att innehåll kan godkännas: WCAG 2.3.1 tillåter blinkande innehåll om det uppfyller något av följande villkor:

• Den kombinerade ytan av blixtar som inträffar samtidigt täcker inte mer än totalt 0,006 steradianer inom något visuellt synfält på 10 grader på skärmen (ungefär en rektangel på 341 × 256 pixlar vid typiska betraktningsavstånd, eller cirka 21 824 kvadratpixlar på en skärm med 1024 pixlars bredd sedd på armlängds avstånd).
• Blixten ligger under det allmänna blixttröskelvärdet (luminansförändringen är mindre än 10%) eller under rött-blixt-tröskelvärdet (den mättade röda komponenten förändras inte mer än det definierade tröskelvärdet).

En enstaka blixt med mycket låg luminanskontrast eller en mycket liten skärmyta kan därför vara tillåten. Eftersom dessa tröskelvärden är nyanserade och kräver fotometriska mätverktyg för att verifieras exakt, väljer de flesta praktiker dock en försiktig strategi och undviker helt enkelt allt innehåll som blinkar mer än tre gånger per sekund. Innehåll som blinkar exakt tre gånger per sekund (3 Hz) ligger på gränsen — innehåll som överstiger 3 Hz är icke-kompatibelt oavsett storlek, om inte storleks- eller luminanströsklarna definitivt uppfylls.

Kriteriet styr allt innehåll som renderas under normal sidinteraktion. Det undantar inte innehåll som är dolt bakom användarutlösta kontroller om det innehållet spelas upp automatiskt vid sidladdning. Om en video börjar spelas automatiskt och innehåller blinksekvenser som överstiger tröskelvärdet, underkänns sidan enligt detta kriterium från det ögonblick den laddas.

Varför det är viktigt

Ljuskänslig epilepsi påverkar ungefär 1 av 4 000 personer globalt — cirka 3% av den totala epilepsibefolkningen. Känslighet för snabbt blinkande eller flimrande ljus är dock mer utbredd än enbart klinisk epilepsi. Många personer med migränsjukdomar, vestibulär dysfunktion, autismspektrumtillstånd och post-commotio-syndrom kan uppleva betydande obehag, desorientering, illamående eller smärta av snabbt blinkande visuella stimuli, även om de inte har en diagnostiserad anfallsstörning.

Insatserna är särskilt höga för detta kriterium jämfört med de flesta andra tillgänglighetskrav. En användare som stöter på saknad alternativtext upplever exkludering och frustration. En användare som stöter på innehåll som utlöser ett ljuskänsligt anfall kan hamna i en medicinsk nödsituation — inklusive medvetslöshet, skador från fall och i sällsynta men dokumenterade fall livshotande konsekvenser. Harding Flash and Pattern Analyzer, ett brett använt verktyg inom tv-branschen, utvecklades specifikt för att förhindra sådana händelser i tv, och webben innebär liknande risker.

Ett konkret scenario från verkligheten illustrerar faran väl: tänk dig en nyhetssajt som automatiskt spelar upp en reklamvideo med en snabb sekvens av växlande ljusa och mörka bildrutor — en vanlig artefakt av vissa videokomprimerings- eller kamerablixt-effekter. En användare med ljuskänslig epilepsi besöker startsidan under sin morgonpendling på en mobil enhet. Utan någon varning och utan möjlighet att inaktivera innehållet exponeras hen för en sekvens som utlöser ett anfall medan hen åker kollektivtrafik. Detta scenario är inte hypotetiskt; det har inträffat i verkliga sammanhang, inklusive det ökända Pokémon-avsnittet 2007 som utlöste anfall hos hundratals tittare i Japan, samt dokumenterade fall som involverar webbaserade annonsenheter.

Utöver säkerhetsdimensionen har efterlevnad av detta kriterium också användbarhetskonsekvenser för allmänheten. Snabbt blinkande innehåll skapar en dålig läsupplevelse, ökar den kognitiva belastningen och anses störande och oprofessionellt i de flesta designkontexter. Att eliminera sådant innehåll förbättrar fokus, minskar avvisningsfrekvensen och signalerar trovärdighet — allt detta bidrar positivt till SEO-mått som vistelsetid och engagemangsgrad. Dessutom tar sökmotorers crawlers i allt högre grad hänsyn till Core Web Vitals och användarupplevelsesignaler i rankningar, och webbplatser med påträngande blinkande annonser eller animationer kan indirekt straffas.

Relaterade Axe-core-regler

WCAG 2.3.1 kräver manuell testning eftersom automatiserade verktyg inte pålitligt kan analysera de fotometriska egenskaperna hos dynamiskt innehåll i realtid. Ingen automatiserad axe-core-regel motsvarar direkt detta kriterium. Skälen till denna begränsning är grundläggande för hur tillgänglighetsautomation fungerar:

• Varför automation misslyckas här: Automatiska skannrar analyserar den statiska DOM:en och CSS vid en given tidpunkt. De kan upptäcka att en animation eller videoelement finns, men de kan inte mäta den faktiska blixtfrekvensen, luminansvärdena i varje bildruta eller den rumsliga ytan av det blinkande området så som det uppfattas av en mänsklig betraktare på ett typiskt betraktningsavstånd. Att avgöra om en blixt överstiger 3 Hz-tröskeln eller 0,006-steradianers ytröskeln kräver fotometrisk analys bildruta för bildruta — en uppgift som kräver dedikerade verktyg som Harding Flash and Pattern Analyzer (HFPA), Photosensitive Epilepsy Analysis Tool (PEAT) eller manuell granskning av animationskällfiler.
• Inbäddad video och tredjepartsinnehåll: Mycket av det mest riskfyllda innehållet (autospelande videoannonser, inbäddade sociala medier-widgets, tredjepartsanimationsbibliotek) laddas från externa domäner. Automatiserade verktyg kan vanligtvis inte komma åt eller analysera innehåll med annan ursprungspolicy på bildrutenivå, vilket gör det omöjligt att programmässigt bedöma blixtfrekvensen i dessa resurser.
• GIF- och canvas-animationer: Animerade GIF-filer och HTML5-canvas-element renderar sina animationsrutor utanför det normala tillgänglighetsträdet. Axe-core och Lighthouse saknar båda möjlighet att avkoda GIF-bildrutors timing eller fånga upp canvas-ritanrop för att beräkna luminansförändringar mellan bildrutor.
• CSS- och JavaScript-animationer: Även om axe-core kan upptäcka förekomsten av CSS-egenskaperna animation eller transition, kan det inte utvärdera om den resulterande visuella utmatningen vid körning ger luminansförändringar som överstiger de allmänna eller röda blixttröskelvärdena.

Eftersom ingen automatiserad regel fångar denna överträdelse vilar hela efterlevnadsbördan på manuell designgranskning, videokontroll före publicering och utvecklarmedvetenhet under innehållsskapandefasen. Detta gör redaktionella och QA-relaterade processkontroller — inte bara teknisk åtgärd — avgörande för hållbar efterlevnad.

Hur man testar

1. Inventera allt dynamiskt innehåll: Innan någon verktygsbaserad testning, granska sidan för allt innehåll som rör sig, blinkar, flimrar eller animeras. Detta inkluderar autospelande videor, animerade GIF:ar, CSS-keyframe-animationer, JavaScript-styrda animationer, SVG-animationer, canvas-element och inbäddade tredjepartswidgets som annonsenheter eller inbäddningar från sociala medier. Dokumentera varje förekomst med dess källa och kontrollmekanism.
2. Använd Photosensitive Epilepsy Analysis Tool (PEAT): PEAT är ett kostnadsfritt verktyg utvecklat av Trace Research and Development Center, specifikt utformat för att analysera videoinnehåll för blixtfaror enligt Harding-specifikationen. Spela in en skärminspelning av webbsidan eller animationen i fråga i full upplösning och importera sedan videofilen till PEAT. Verktyget rapporterar om någon sekvens överstiger det allmänna blixttröskelvärdet eller rött-blixt-tröskelvärdet och vid vilka tidsstämplar.
3. Använd Harding Flash and Pattern Analyzer för innehåll i broadcast-kvalitet: För videoinnehåll som ska bäddas in från produktionsflöden (t.ex. tv-bolagswebbplatser, nyhetsorganisationer), kör källvideofiler genom HFPA innan publicering. Detta är guldstandardverktyget för förhandsgranskning före publicering.
4. Manuell observation — tre-blixt-räkningen: För CSS-animationer, JavaScript-effekter eller GIF-filer där verktygsbaserad analys är opraktisk, spela upp animationen och försök räkna antalet kompletta ljus–mörk–ljus-cykler under en enda sekund. Om du observerar tre eller fler kompletta cykler per sekund är innehållet sannolikt icke-kompatibelt. Använd skärminspelningsprogram med uppspelning bildruta för bildruta för att underlätta denna räkning.
5. Kontrollera videoinnehåll bildruta för bildruta: Öppna videofiler i ett videoredigeringsprogram (som DaVinci Resolve, gratisversionen) som visar vågforms- eller histogramdata på bildrutenivå. Skjut genom sektioner med snabba visuella förändringar och kontrollera efter växlande hög–låg-luminansmönster som inträffar mer än tre gånger per sekund. Titta särskilt efter sekvenser som involverar mättad röd mot mörka bakgrunder.
6. Testa med webbläsarens utvecklarverktyg för CSS-animationer: I Chrome DevTools, öppna panelen Animations (More Tools → Animations). Inspektera deklarerade animationslängder och iterationscykler. En animation med en längd på mindre än 333 millisekunder som växlar mellan högkontrasttillstånd vid varje iteration kommer att överstiga 3 Hz-tröskeln. Beräkna: om en fullständig ljus–mörk–ljus-cykel slutförs på under 333 ms är innehållet icke-kompatibelt.
7. Bedöm den rumsliga ytan för gränsfall: Om innehåll blinkar med en frekvens över 3 Hz men verkar mycket litet på skärmen, mät dess pixeldimensioner. På en skärm med 1024 pixlars bredd vid normalt betraktningsavstånd (ungefär 57–60 cm) är den säkra ytröskeln cirka 21 824 kvadratpixlar. Multiplicera bredden och höjden på det blinkande området; om resultatet är under denna tröskel kan innehållet falla inom undantaget för säker yta — men dokumentera denna bedömning noggrant.
8. Testa autospelande video vid sidladdning: Inaktivera all interaktion med sidan efter att den har laddats och observera om någon video eller animation börjar spelas automatiskt. Om den gör det, tillämpa testerna ovan på det autospelande innehållet omedelbart, eftersom användaren inte har någon möjlighet att ingripa innan exponering.

Hur man åtgärdar

Autospelande GIF med snabb blixt — Felaktigt

<!-- An animated GIF that cycles between a bright yellow and black frame
     at approximately 10 times per second, far exceeding the 3 Hz threshold -->
<img src='attention-flash.gif' alt='Special offer alert' width='600' height='300'>

Autospelande GIF med snabb blixt — Korrekt

<!-- Replace the flashing GIF with a static image and use a subtle CSS
     animation that does not alter luminance rapidly. The animation here
     uses a gentle scale pulse at a rate well below 3 Hz (one cycle per 2 seconds). -->
<img src='attention-static.png'
     alt='Special offer alert'
     class='pulse-attention'
     width='600'
     height='300'>

<style>
  @keyframes gentlePulse {
    0%, 100% { transform: scale(1); }
    50% { transform: scale(1.03); }
  }
  .pulse-attention {
    animation: gentlePulse 2s ease-in-out infinite;
  }
</style>

CSS-keyframe-animation som blinkar mellan högkontrastfärger — Felaktigt

<!-- A CSS animation that alternates a banner between white and black
     with a 100ms total duration, producing 10 flashes per second -->
<div class='flash-banner'>SALE NOW ON</div>

<style>
  @keyframes flashEffect {
    0% { background-color: #ffffff; color: #000000; }
    50% { background-color: #000000; color: #ffffff; }
    100% { background-color: #ffffff; color: #000000; }
  }
  .flash-banner {
    animation: flashEffect 0.1s linear infinite;
  }
</style>

CSS-keyframe-animation som blinkar mellan högkontrastfärger — Korrekt

<!-- Slowing the animation duration to 1 second per full cycle means
     the luminance alternates once per second (1 Hz), well below the 3 Hz limit.
     Alternatively, use prefers-reduced-motion to disable animation entirely
     for users who have opted into reduced motion at the OS level. -->
<div class='flash-banner'>SALE NOW ON</div>

<style>
  @keyframes flashEffect {
    0% { background-color: #ffffff; color: #000000; }
    50% { background-color: #000000; color: #ffffff; }
    100% { background-color: #ffffff; color: #000000; }
  }
  .flash-banner {
    animation: flashEffect 1s linear infinite;
  }

  @media (prefers-reduced-motion: reduce) {
    .flash-banner {
      animation: none;
      background-color: #1a1a8c;
      color: #ffffff;
    }
  }
</style>

Inbäddad autospelande video med blixtsekvenser — Felaktigt

<!-- Auto-playing video with no controls, no PEAT analysis performed,
     and no mechanism for the user to stop or pause before exposure -->
<video src='promo.mp4' autoplay loop muted width='800' height='450'></video>

Inbäddad autospelande video med blixtsekvenser — Korrekt

<!-- Best practice: provide controls so users can pause immediately,
     add a poster frame so no video plays without interaction,
     or use preload='none' to prevent auto-loading. If autoplay is
     genuinely required by business logic, the video MUST have been
     screened with PEAT or HFPA and confirmed free of flash hazards. -->
<video
  src='promo-screened.mp4'
  controls
  muted
  preload='metadata'
  poster='promo-poster.jpg'
  width='800'
  height='450'>
  <track kind='captions' src='promo-captions.vtt' srclang='tr' label='Türkçe'>
</video>
<p>Bu video flaş analizi aracıyla (PEAT) incelenmiş ve güvenli bulunmuştur.</p>

Vanliga misstag

• Att anta att GIF-filer är säkra som standard: Många utvecklare tror att eftersom animerade GIF:ar är ett äldre format är de i sig ofarliga. I verkligheten kan GIF:ar växla mellan bildrutor med frekvenser som överstiger 3 Hz, och formatet har ingen teknisk begränsning för bildfrekvens. Varje GIF med växlande högkontrastbildrutor måste tidsbestämmas och utvärderas.
• Att förbise tredjepartsannons-skript: Displayannonsnätverk levererar ofta kreativa enheter som innehåller blinkande eller flimrande animationer. Publicister som bäddar in annons-taggar utan att granska det kreativa innehållet är fortfarande ansvariga för eventuella WCAG 2.3.1-överträdelser som dessa annonser orsakar på deras sidor. Inför policys för granskning av annonsmaterial och avtalskrav med annonsnätverk.
• Att blanda ihop WCAG 2.3.1 med WCAG 2.2.2 (Pausa, Stoppa, Dölj): Vissa team åtgärdar symptomet genom att lägga till en pausknapp (vilket uppfyller 2.2.2) men åtgärdar inte den underliggande blixtfrekvensen (som bryter mot 2.3.1). De två kriterierna är oberoende: en pauskontroll gör inte i efterhand innehåll som redan har börjat blinka kompatibelt med 2.3.1, eftersom användaren exponeras innan hen kan interagera.
• Att inte beakta rött-blixt-tröskelvärdet separat: Utvecklare som känner till den allmänna 3 Hz-tröskeln förbiser ibland det separata rött-blixt-tröskelvärdet. Innehåll som involverar snabbt växlande mättade röda värden kan utlösa ljuskänsliga anfall även vid frekvenser något under 3 Hz hos vissa individer. Animationer med mättad röd bör granskas med särskild noggrannhet.
• Att ignorera innehåll som laddas i iframes: Sidor som bäddar in tredjepartsinnehåll via <iframe>-element — inklusive widgets för sociala medier, livechattverktyg eller inbäddade dashboards — är ansvariga för tillgängligheten hos det innehållet så som det renderas på deras sida. Blixtfaror i en iframe är lika farliga som de i huvuddokumentet.
• Att hoppa över implementering av mediafrågan prefers-reduced-motion: Även när grundanimationer ligger under 3 Hz-tröskeln innebär underlåtenhet att implementera @media (prefers-reduced-motion: reduce) att användare som har angett OS-nivåpreferenser för minskad rörelse inte får någon anpassning. Även om detta främst behandlas av WCAG 2.3.3 på AAA-nivå är det en lågkostnads- och högpåverkan-praxis att inkludera mediafrågan, som visar tillgänglighetsengagemang och minskar risk.
• Att använda JavaScript setInterval eller requestAnimationFrame utan frekvensbegränsning: Animationer som drivs av setInterval(fn, 50) körs var 50:e millisekund och ger 20 cykler per sekund — långt över 3 Hz-gränsen. Utvecklare måste uttryckligen beräkna intervallängden som krävs för att hålla sig vid eller under en förändring per 333 ms för alla animationer som ändrar luminans.
• Att inte granska videoinnehåll före publicering: Många organisationer har ett publiceringsflöde som inkluderar visuell QA och upphovsrättsgranskning men saknar ett steg för granskning av blixtfaror. Utan att integrera PEAT eller HFPA i förpubliceringsprocessen kan ljuskänslighetsfaror i videoinnehåll förbli oupptäckta tills de orsakar skada.
• Att behandla storleksundantaget som lätt att utnyttja: Vissa utvecklare får kännedom om undantaget för säker yta på 0,006 steradianer och försöker använda det för att motivera att farliga blixt-effekter får vara kvar genom att göra dem små. I praktiken kräver en korrekt beräkning av om innehåll hamnar inom tröskeln kunskap om användarens betraktningsavstånd och skärmupplösning — variabler som utvecklaren inte kan kontrollera. Att förlita sig på storleksundantaget utan fotometrisk mätning är riskabelt och juridiskt osäkert.
• Att inte dokumentera bedömningar av blixtfaror: Organisationer som testar video- eller animationsinnehåll för blixtfaror misslyckas ofta med att spara dokumentation av dessa bedömningar. Vid ett användarklagomål eller en tillsynsgranskning är dokumenterade bevis på att PEAT- eller HFPA-granskning genomfördes och att innehållet bedömdes som kompatibelt avgörande för att visa aktsamhet.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentcirkulär 2025/10, publicerat i Officiella tidningen nr 32933 den 21 juni 2025, fastställer obligatoriska krav på webb- och mobiltillgänglighet i linje med WCAG 2.2. WCAG 2.3.1, som ett framgångskriterium på nivå A, omfattas av obligatorisk efterlevnad för alla berörda aktörer.

Cirkuläret definierar en stegvis tidsplan för efterlevnad: offentliga institutioner och myndigheter måste uppnå full överensstämmelse med nivå A inom ett år från cirkulärets ikraftträdande, medan privata aktörer som omfattas av regleringen har två år på sig att uppfylla kraven. Med tanke på den säkerhetskritiska karaktären hos WCAG 2.3.1 — som direkt relaterar till risken att utlösa medicinska nödsituationer hos användare — innebär bristande efterlevnad av just detta kriterium en förhöjd reputations- och rättslig risk, även i förhållande till andra krav på nivå A.

Följande aktörstyper omfattas uttryckligen av presidentcirkulär 2025/10 och måste därför följa WCAG 2.3.1:

• Offentliga institutioner och myndigheter: Alla centrala och lokala statliga organ, ministerier, kommuner och statsanknutna organisationer som driver publika webbplatser eller mobilapplikationer.
• E-handelsplattformar: Nätbutiker och marknadsplatsoperatörer som tillhandahåller varor eller tjänster till konsumenter via digitala plattformar, oavsett sektor.
• Banker och finansiella institutioner: Alla licensierade banker, deltagandebanker, värdepappersbolag och fintech-aktörer som tillhandahåller digitala bank- eller finanstjänster.
• Sjukhus och vårdgivare: Offentliga och privata sjukhus, polikliniker och vårdnätverk som erbjuder patientinriktade digitala tjänster, inklusive tidsbokning och patientportaler.
• Telekomföretag med 200 000 eller fler abonnenter: Större mobilnätsoperatörer och internetleverantörer som uppfyller abonnenttröskeln, inklusive deras självbetjäningsportaler och mobilapplikationer.
• Resebyråer: Licensierade rese- och turismbyråer som erbjuder onlinebokning, reservation eller informationstjänster.
• Privata transportföretag: Flygbolag, fjärrbussoperatörer, färjeoperatörer och andra privata transportleverantörer med konsumentinriktade digitala plattformar.
• Privatskolor auktoriserade av Ministeriet för nationell utbildning (MoNE): Privata utbildningsinstitutioner med MoNE-auktorisation som driver webbplatser eller digitala lärplattformar.

För berörda aktörer kräver efterlevnad av WCAG 2.3.1 inte bara en engångsrevision utan ett löpande operativt åtagande. Eftersom blixtfaror oftast introduceras genom dynamiskt innehåll — videouppladdningar, marknadsföringsanimationer, tredjepartsannonser — måste organisationer integrera granskning av blixtfaror i sina innehållspubliceringsflöden, inte enbart i den initiala sajtgranskningen. Användning av verktyg som PEAT för förhandsgranskning av video, i kombination med utvecklarutbildning om säkra animationsfrekvenser och implementering av CSS-prefers-reduced-motion, utgör den minimistandard för operativ aktsamhet som förväntas av berörda aktörer enligt cirkuläret. Organisationer som förlitar sig på tredjepartsinnehållshantering eller annonsystem måste också säkerställa avtalsbestämmelser som kräver WCAG 2.3.1-efterlevnad från sina leverantörer, eftersom det regulatoriska ansvaret vilar på den aktör som driver den publika digitala tjänsten.