WCAG 2.3.2: Üç Flaş

Bu Kuralın Anlamı

WCAG 2.3.2 Üç Flaş, Kullanılabilirlik ilkesinin altında yer alan Seviye AAA başarı ölçütüdür. Web sayfalarının herhangi bir bir saniyelik zaman diliminde üç kereden fazla flaş yapan hiçbir içerik barındırmaması gerektiğini belirtir. Seviye AA karşılığı (2.3.1 Üç Flaş veya Eşik Altında) ile karşılaştırıldığında, bu ölçüt küçük flaş alanları veya genel flaş ve kırmızı flaş eşiklerinin altında kalan flaşlar için hiçbir istisna tanımaz. Kural kesindir: içerik saniyede üç kereden fazla flaş yapıyorsa, boyut, renk veya kontrast ne olursa olsun başarısız olur.

Flaş, WCAG tarafından, bazı kişilerde nöbetlere neden olabilen, göreli parlaklıkta zıt yönde gerçekleşen iki değişim çifti olarak tanımlanır. Daha pratik olarak, saniyede üç tam döngüden fazlasını tamamlayan, görünür açılıp-kapanan yanıp sönmeler, stroboskop benzeri animasyonlar, hızla döngüye giren görüntüler veya titreyen videolar bu kuralın kapsamına girer. "Üç flaş" terimi üç tam salınıma atıfta bulunur — yani içeriğin tek bir saniye içinde daha açık ve daha koyu durumlar arasında üç kez gidip gelmesi anlamına gelir.

Etkilenen içerik türleri geniştir ve animasyonlu GIF’leri, @keyframes kullanan CSS animasyonlarını, hızlı görsel geçişlere neden olan JavaScript tabanlı DOM güncellemelerini, HTML5 Canvas animasyonlarını, gömülü video içeriğini, SVG animasyonlarını ve animasyonlu medya yerleştiren üçüncü taraf reklam ağlarını veya bileşenlerini içerir. Kayar yazı (marquee) metnindeki hafif titremeler veya hızla güncellenen veri görselleştirmeleri bile, hız saniyede üç flaşı aştığında bu ölçütü tetikleyebilir.

2.3.2 kapsamında bir geçiş, sayfanın üç-flaş-saniye eşiğini aşan hiçbir flaş içeriği barındırmaması anlamına gelir. Başarısızlık ise, sayfanın herhangi bir bölümünün — alan ne kadar küçük olursa olsun — herhangi bir bir saniyelik zaman aralığında üç kereden fazla flaş yapması durumunda ortaya çıkar. Bu ölçüt kapsamında güvenli alan istisnası yoktur; bu da onu 2.3.1’den ayırır. Küçük bir yanıp sönen imleç, animasyonlu bir yükleme simgesi veya hızla döngüye giren bir reklam bandı, 3 Hz’i aşan frekanslarda flaş yapıyorsa hepsi birer başarısızlık sayılabilir.

Neden Önemlidir

Fotosensitif epilepsi dünya genelinde yaklaşık her 4.000 kişiden 1’ini etkiler, ancak fotosensitif migrenler, vestibüler bozukluklar ve epileptik olmayan fotosensitivite dahil olmak üzere, bir tür fotosensitif nörolojik tepkiye yatkın toplam nüfus önemli ölçüde daha büyüktür. Bu kişiler için ekranda hızla flaş yapan içeriğe maruz kalmak basit bir rahatsızlık değildir: büyük nöbetleri, bilinç kaybını, yaralanmayı veya nadir durumlarda ölümü tetikleyebilir. Kullanıcı deneyimini bozan birçok erişilebilirlik engelinin aksine, flaş içeriği akut bir güvenlik tehlikesi oluşturur.

Pratik bir senaryo düşünün: Bir Türk haber sitesi, son dakika haberlerine dikkat çekmek için 8 Hz’de nabız atan animasyonlu bir vurgulama efektiyle canlı bir bant (ticker) gömer. Fotosensitif epilepsisi olan bir kullanıcı, işe gidip gelirken sayfayı telefonunda açar. Saniyeler içinde, hızlı titreme odak nöbetini tetikler, kişinin telefonunu düşürmesine ve kısa süreli kas kontrolünü kaybetmesine neden olur. Önceden bir uyarı yoktur, efekti önceden devre dışı bırakma imkânı yoktur ve başvurabileceği bir yol yoktur. Bu senaryo, flaş hızlarını saniyede üç veya daha azla sınırlayarak — ya da 2.3.2’nin gerektirdiği gibi flaş içeriğini tamamen ortadan kaldırarak — tamamen önlenebilir.

Nörolojik güvenlik boyutunun ötesinde, bu ölçüte uymak vestibüler bozukluğu olan (hareketten baş dönmesi, mide bulantısı veya yönelim bozukluğu yaşayan) kullanıcılar, görsel desenlerle tetiklenen migreni olan kullanıcılar ve hızla flaş yapan içeriği görmezden gelmesi veya etrafından dolaşması imkânsız bulan dikkat eksikliği bozukluğu olan kullanıcılar için de faydalıdır. Flaş içeriğini azaltmak veya ortadan kaldırmak, sayfanın algılanan profesyonellik düzeyini artırma ve kullanıcı terk oranlarını azaltma eğilimindedir; çünkü birçok kullanıcı — engelli olsun olmasın — agresif animasyonları rahatsız edici bulur.

SEO ve performans açısından bakıldığında, ağır animasyonları ve hızlı CSS geçişlerini ortadan kaldırmak CPU ve GPU yükünü azaltır, Google sıralama sinyalleri olan Toplam Engelleme Süresi (Total Blocking Time) ve Kümülatif Düzen Kayması (Cumulative Layout Shift) gibi Core Web Vitals puanlarını iyileştirir.

İlgili Axe-core Kuralları

WCAG 2.3.2 manuel test gerektirir. Bu ölçüte doğrudan karşılık gelen otomatik bir axe-core kuralı yoktur ve bu kasıtlıdır — işte otomatik araçların ihlalleri neden güvenilir şekilde yakalayamadığı:

• Manuel test gerekli — Flaş hızı tespiti: Otomatik erişilebilirlik tarayıcıları statik DOM ve CSS’yi tek bir anda inceler. İçeriğin bir saniyelik animasyon oynatımı boyunca nasıl davrandığını gözlemleyemez, bir video veya animasyonlu GIF’in parlaklık salınım frekansını ölçemez veya bir Canvas animasyonunun kare hızını değerlendiremezler. Flaş hızı, gerçek zamanlı gözlem gerektiren zamansal bir özelliktir ve bu da onu axe-core gibi statik analiz araçlarının erişiminin temelde dışında bırakır. Bir insan testçi — veya Photosensitive Epilepsy Analysis Tool (PEAT) gibi özel fotosensitivite analiz araçları — animasyonlu içeriği hareket halinde inceleyerek üç-flaş-saniye eşiğini aşıp aşmadığını belirlemelidir.
• Manuel test gerekli — Üçüncü taraf ve gömülü içerik: Reklamlar, gömülü videolar, sosyal medya bileşenleri ve iframe’ler, axe-core’un analiz edemeyeceği animasyonlu içerik enjekte edebilir; çünkü axe-core tarayıcıdaki aynı kaynak politikası kısıtları içinde çalışır. Bir testçi, uyumluluğu değerlendirmek için oynatma sırasında tüm gömülü ve üçüncü taraf içeriği manuel olarak gözlemlemelidir.
• Manuel test gerekli — JavaScript tabanlı animasyonlar: CSS sınıflarını hızla değiştirmek, canvas piksellerini güncellemek veya SVG öğelerini JavaScript ile yüksek frekansta manipüle etmek, statik bir DOM anlık görüntüsünde görünmeyen flaş efektleri üretebilir. Testçiler sayfayı canlı bir tarayıcıda çalıştırmalı, tüm animasyonlu durumları gözlemlemeli ve flaş döngülerini manuel olarak veya kare hızı analiz araçlarıyla zamanlamalıdır.

Nasıl Test Edilir

1. Temel olarak otomatik bir tarama çalıştırın: Animasyonla ilgili işaretlenmiş sorunları belirlemek için axe DevTools, Lighthouse veya Accsible bileşeninin yerleşik denetimini kullanın. Her ne kadar 2.3.2’ye doğrudan karşılık gelen bir kural olmasa da, bu araçlar hızlı CSS animasyonları veya hızla güncellenen ARIA canlı bölgeleri hakkında ilgili uyarılar verebilir. İşaretlenen öğeleri not edin, ancak temiz bir otomatik raporun 2.3.2 uyumluluğunu doğrulamadığını unutmayın.
2. Tüm animasyonlu içeriği manuel olarak belirleyin: Sayfayı bir tarayıcıda yükleyin ve etkileşime girmeden en az 30 saniye boyunca gözlemleyin. Yanıp sönen, flaş yapan, animasyonlu olan veya görsel durumunu tekrar tekrar değiştiren her öğeyi not edin. Yükleme simgelerini, banner’ları, kahraman (hero) animasyonlarını, otomatik oynatılan videoları, animasyonlu arka planları ve tüm üçüncü taraf bileşenleri dahil edin. Bu öğelerin bir envanterini oluşturun.
3. Photosensitive Epilepsy Analysis Tool (PEAT) kullanın: Video içeriği veya animasyonların ekran kayıtları için, kare kare analiz etmek üzere PEAT’i (Trace Research and Development Center tarafından sunulan ücretsiz bir araç) kullanın. PEAT, flaş eşiklerini aşan tüm dizileri işaretler ve hem genel flaş eşiğini hem de kırmızı flaş eşiğini raporlar. 2.3.2 başarısızlığı, diğer eşiklerden bağımsız olarak saniyede üçten fazla olan herhangi bir flaştır.
4. CSS ve JavaScript animasyon hızlarını ölçün: Tarayıcı Geliştirici Araçlarını (Chrome veya Firefox) açın ve animasyonlar oynarken Performans sekmesini kullanarak 5 saniyelik bir oturum kaydedin. Alev grafiğini (flame graph) hızlı tekrarlanan paint veya layout işlemleri için inceleyin. Ayrıca Chrome DevTools’taki Animations panelini açarak çalışan animasyonları ve sürelerini görebilirsiniz — Hz’i hesaplamak için 1000ms’yi animasyon süresine bölün.
5. NVDA + Firefox, VoiceOver + Safari ve JAWS + Chrome ile test edin: Ekran okuyucu kullanıcıları fotosensitiviteden muaf değildir. Her ekran okuyucuyu başlatın ve sayfada normal şekilde gezinin. Görsel olarak flaş yapan herhangi bir içerik, aynı zamanda hızlı ekran yenilemelerine neden olacak şekilde sunuluyorsa (örneğin bir sayacın her karesini duyuran canlı bir bölge gibi), bunu belgeleyin. Görsel flaş, ekran okuyucu kullanıcıları için de ihlal olmaya devam eder; çünkü bu kullanıcıların bir kısmının işlevsel görme yetisi olabilir.
6. Üçüncü taraf ve gömülü içeriği doğrulayın: Tüm iframe’ler, gömülü sosyal medya gönderileri, reklam alanları ve video oynatıcılar boyunca kaydırın. Otomatik oynatma devre dışı bırakılmış videoları manuel olarak oynatın ve hızlı titreme açısından gözlemleyin. Animasyonlu GIF’leri, sağ tıklayıp bir resim düzenleyicide veya tarayıcının Network sekmesinde kare verilerini inceleyerek kare hızını tahmin etmek için kontrol edin.
7. Cihazlar ve tarayıcılar arasında testleri tekrarlayın: Bazı animasyonlar, donanım hızlandırma farklılıkları nedeniyle mobilde masaüstüne göre farklı hızlarda çalışır. Hem masaüstü bir tarayıcıda hem de bir mobil cihazda (iOS Safari ve Android Chrome) test ederek tutarlı uyumluluğu doğrulayın.

Nasıl Düzeltilir

CSS Keyframe Animasyonu Çok Hızlı Flaş Yapıyor — Yanlış

<!-- Dikkat çekmek için saniyede 8 döngü tamamlayan yanıp sönen bir rozet -->
<style>
  @keyframes flash-badge {
    0%, 49% { background-color: red; }
    50%, 100% { background-color: transparent; }
  }
  .alert-badge {
    animation: flash-badge 0.125s infinite; /* 8 Hz — saniyede 3'ü fazlasıyla aşıyor */
  }
</style>
<span class='alert-badge'>NEW</span>

CSS Keyframe Animasyonu Çok Hızlı Flaş Yapıyor — Doğru

<!-- Animasyon saniyede 3'ten az döngü tamamlayacak şekilde yavaşlatıldı -->
<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 — 3 Hz eşiğinin güvenli şekilde altında */
  }
</style>
<span class='alert-badge'>NEW</span>
<!-- Daha da iyisi: animasyonu tamamen kaldırın ve statik, yüksek kontrastlı bir rozet kullanın -->

JavaScript DOM Geçişi Hızlı Titremeye Neden Oluyor — Yanlış

<!-- Betik, stroboskop etkisi oluşturmak için görünürlüğü saniyede 10 kez değiştiriyor -->
<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); /* Her 100ms'de bir çalışır = saniyede 10 flaş -- ciddi bir nöbet riski */
</script>

JavaScript DOM Geçişi Hızlı Titremeye Neden Oluyor — Doğru

<!-- Hızlı geçiş tamamen kaldırıldı; durum değişikliğini bunun yerine metin veya ikonla iletin -->
<div id='status-element' style='width:200px;height:200px;background:#005fcc;'>
  <p style='color:white;padding:1rem;'>System Active</p>
</div>
<!-- Animasyon gerçekten gerekliyse, hızını 3 Hz'in oldukça altında tutun ve yüksek kontrastlı
     parlaklık geçişleri yerine opaklık/renk geçişlerini tercih edin -->

Yüksek Kare Hızına Sahip Animasyonlu GIF — Yanlış

<!-- Kareleri saniyede 10 kez döngüye sokan animasyonlu bir GIF reklamı -->
<img src='promo-flash.gif' alt='Special offer — 50% off this weekend only'>
<!-- GIF'in dahili kare gecikmesi kare başına 10ms olarak ayarlanmış, bu da hızlı titreme yaratıyor -->

Yüksek Kare Hızına Sahip Animasyonlu GIF — Doğru

<!-- Animasyonlu GIF'i statik bir görselle değiştirin veya GIF'i kare başına
     minimum 334ms gecikmeyle (3 fps veya daha yavaş) yeniden dışa aktarın -->
<img src='promo-static.png' alt='Special offer — 50% off this weekend only'>
<!-- Hareket korunmak zorundaysa, prefers-reduced-motion desteği olan bir CSS animasyonu kullanın -->
<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>

Yaygın Hatalar

• 2.3.1’deki "küçük alan" istisnasının 2.3.2 için de geçerli olduğunu varsaymak: WCAG 2.3.1, 10 derecelik bir görsel alanın %25’inden azını kaplayan flaş içeriğe izin verir. WCAG 2.3.2’de böyle bir istisna yoktur — saniyede üçten fazla flaş yapan küçük bir yanıp sönen imleç veya küçük bir yükleme noktası bile AAA seviyesinde tam bir ihlaldir.
• Ortaya çıkan flaş hızını hesaplamadan CSS animation-duration değerlerini 0.1s veya 0.2s gibi ayarlamak: İki durum arasında salınan 0.1s’lik bir animasyon saniyede 10 döngü (10 Hz) tamamlar. Hz’i bulmak için saniye cinsinden süreyi 1’e bölün; sonucun 3 veya altında olduğundan emin olun.
• Animasyon davranışını gözden geçirmeden üçüncü taraf reklam betiklerini gömmek: Reklam ağları, tıklama oranı için optimize edilmiş, erişilebilirlik için değil, yüksek flaş hızlarına sahip animasyonlu kreatifler sunar. Üçüncü taraf içeriği dağıtmadan önce her zaman PEAT veya manuel kare incelemesiyle denetleyin.
• Yükleme veya ilerleme göstergeleri için CSS sınıflarını hızla değiştirmek üzere setInterval veya requestAnimationFrame döngüleri kullanmak: Bir öğenin parlaklığını veya görünürlüğünü saniyede üçten fazla değiştiren herhangi bir JavaScript döngüsü, normal görüntüleme koşullarında efekt ince görünse bile 2.3.2 ihlali oluşturur.
• Animasyonlu SVG’leri ve Canvas öğelerini test etmemek: <animate> veya SMIL kullanan SVG animasyonları ve Canvas tabanlı oyunlar veya veri görselleştirmeleri, nadiren PEAT veya kare hızı araçlarıyla test edilir; ancak flaş eşiğini aşma kapasitesine tamamen sahiptirler.
• 2.3.2 uyumluluğunu doğrulamak için yalnızca axe-core veya Lighthouse’a güvenmek: Otomatik araçlar bu ölçütü tespit edemez. Temiz bir otomatik tarama sonucu 2.3.2 için hiçbir şey ifade etmez; uyumluluğu yalnızca manuel inceleme ve PEAT analizi doğrulayabilir.
• prefers-reduced-motion’ı 2.3.2 için tam bir çözüm olarak görmek: prefers-reduced-motion medya sorgusuna saygı göstermek iyi bir uygulamadır ve birçok kullanıcı için faydalıdır, ancak bu kullanıcı tarafından etkinleştirilen bir mekanizmadır. WCAG 2.3.2, içeriğin varsayılan olarak güvenli olmasını gerektirir; yalnızca kullanıcının bir sistem tercihi ayarladığı durumlarda değil. Bu ayarı yapılandırmamış kullanıcılar risk altında kalmaya devam eder.
• Flaş hızı sınırlarını yalnızca videoya uygulayıp CSS, JavaScript veya GIF animasyonlarına uygulamamak: Ekipler bazen video içeriğini PEAT ile denetler, ancak CSS keyframe animasyonlarını ve JavaScript tabanlı geçişleri gözden kaçırır. Tüm animasyon teknolojileri değerlendirilmelidir.
• Animasyonlu GIF’leri göstermek için background-image CSS özelliklerini kullanmak: CSS arka plan görüntüleri olarak ayarlanan animasyonlu GIF’ler, görsel tarama yapan testçiler için daha az görünürdür ve denetimler sırasında kolayca gözden kaçabilir. Animasyon envanterinize her zaman arka plan görüntülerini de dahil edin.
• A/B testleri veya kişiselleştirme değişiklikleri yeni animasyonlu içerik enjekte ettikten sonra yeniden test etmemek: Pazarlama ve kişiselleştirme sistemleri, WCAG 2.3.2 uyumluluğu için hiç incelenmemiş animasyonlu banner’lar veya katmanlar dinamik olarak enjekte edebilir. Dinamik olarak enjekte edilen tüm içerik için bir inceleme kapısı oluşturun.

Türkiye’nin Erişilebilirlik Mevzuatıyla İlişkisi

21 Haziran 2025 tarihli ve 32933 sayılı Resmî Gazete’de yayımlanan Türkiye Cumhurbaşkanlığı Genelgesi 2025/10, Türkiye’de faaliyet gösteren geniş bir yelpazedeki kuruluş için zorunlu web ve mobil erişilebilirlik standartlarını belirler. Genelge, teknik referans çerçevesi olarak WCAG 2.2’yi benimser ve genel olarak Seviye A ve Seviye AA düzeylerinde uyumu zorunlu kılar.

WCAG 2.3.2 bir Seviye AAA ölçütüdür ve bu nedenle genelge kapsamında yer alan çoğu kuruluş için hukuken zorunlu değildir. Ancak, içeriğin nöbetleri tetikleyebilmesini önleme konusu, düzenlemenin temelini oluşturan özen yükümlülüğü ve ayrımcılık yapmama ilkeleriyle doğrudan kesişir. Genelge kapsamında olan ve 2.3.2’yi, sıkı anlamda zorunlu olmasa bile güçlü bir en iyi uygulama yükümlülüğü olarak görmesi gereken kuruluş türleri şunlardır: e-ticaret platformları, kamu kurumları ve devlet daireleri, bankalar ve finans kuruluşları, hastaneler ve sağlık hizmeti sağlayıcıları, 200.000 veya daha fazla abonesi olan telekomünikasyon şirketleri, seyahat acenteleri, özel ulaşım şirketleri ve Millî Eğitim Bakanlığı (MoNE) tarafından yetkilendirilmiş özel okullar.

Özellikle kamu kurumları ve sağlık hizmeti sağlayıcıları için 2.3.2’nin etik boyutu son derece yüksektir. Fotosensitif bir ziyaretçide nöbet tetikleyen bir devlet sağlık portalı veya hastane hasta bilgilendirme sayfası, hem bir güvenlik başarısızlığını hem de itibar krizini temsil eder. Genelge AAA uyumluluğunu açıkça zorunlu kılmasa da, ister ihale yeterliliği, ister kamu güveni, ister uluslararası iş ortaklıkları için olsun, en üst düzey erişilebilirlik sergilemek isteyen kuruluşlar, zorunlu A ve AA yükümlülüklerinin yanında 2.3.2’yi de uygulamalıdır.

Avrupa Birliği pazarına hizmet sunan kuruluşlar, Haziran 2025’te uygulamaya giren Avrupa Erişilebilirlik Yasası’nın (EAA) EN 301 549’a atıfta bulunduğunu, EN 301 549’un da WCAG’e atıfta bulunduğunu not etmelidir. AB üye devletlerine dijital ürün veya hizmet ihraç eden Türk şirketleri, bu kanal üzerinden daha sıkı gerekliliklerle karşılaşabilir. 2.3.2’yi proaktif olarak uygulamak, Türk kuruluşlarını hem yerel hem de sınır ötesi uyumluluk için iyi bir konuma getirir.

Pratik uygulama açısından, Accsible katman bileşeni SDK’sı, kapsamdaki kuruluşlara, kullanıcıların sayfadaki tüm animasyonları duraklatma veya durdurma seçeneğini sunarak, durumlarının farkında olan kullanıcılar için fotosensitivite riskini azaltmaya yardımcı olabilir. Ancak bu kullanıcı tetiklemeli kontrol, 2.3.2’nin gerektirdiği gibi flaş içeriğini kaynağında kaldırmanın veya yavaşlatmanın yerine geçen bir çözüm değil, tamamlayıcı bir önlemdir.