WCAG 2.2.4: Kesintiler

Bu Kuralın Anlamı

WCAG 2.2.4: Kesintiler, 2.2 (Yeterli Zaman) Kılavuzu altında Seviye AAA başarı ölçütüdür. Şöyle der: "Acil durum içeren kesintiler hariç, kesintiler kullanıcı tarafından ertelenebilir veya bastırılabilir." Pratikte bu, kullanıcı tarafından doğrudan başlatılmadan ortaya çıkan herhangi bir içerik, uyarı, bildirim, iletişim kutusu veya güncellemenin — yangın alarmı, hayatı tehdit eden tıbbi uyarı veya kritik sistem arızası gibi gerçek bir acil durumu iletmediği sürece — kullanıcıya bunu erteleyebileceği veya devre dışı bırakabileceği bir mekanizma sunması gerektiği anlamına gelir.

WCAG anlamında bir kesinti, kullanıcının mevcut eyleminden bağımsız olarak gerçekleşen ve kullanıcının yaptığı işten dikkatini uzaklaştıran herhangi bir olaydır. Buna, ancak bunlarla sınırlı olmamak üzere, tost bildirimleri, anlık bildirimler, kendiliğinden açılan sohbet bileşenleri, yenilenen veya değişen durum bantları, otomatik oynatılan medya, JavaScript tarafından enjekte edilen canlı bölge duyuruları, zamanlayıcıyla tetiklenen modal iletişim kutuları ve oturum ortasında beliren çerez onay bantları dahildir. Ölçüt bu kalıpları tamamen yasaklamaz; kullanıcıların bunlar üzerinde kontrol sahibi olmasını şart koşar.

Bir sayfa, her acil durum dışı kesintinin şu seçeneklerden en az birine sahip olması durumunda 2.2.4’ü geçer: kesinti gerçekleşmeden önce onu devre dışı bırakmaya yarayan kullanıcıya açık bir ayar, kesintinin içinde onu kapatmaya veya ertelemeye yarayan bir mekanizma veya bu tür kesintileri tamamen bastıran genel bir site düzeyi tercihi. Bir sayfa, kesintiler kendiliğinden ortaya çıktığında, kapatma veya erteleme mekanizması sunmadığında ve bir acil durumla ilgili olmadığında kalır. Örneğin, 10 saniye sonra kendiliğinden genişleyen ve kapatma düğmesi olmayan bir canlı sohbet balonu veya pazarlama mesajları arasında dönen ve durdurulamayan bir bildirim bandı, her ikisi de başarısız olur.

Açıkça tanımlanmış tek istisna acil durumlardır. İçerik, sağlık, güvenlik veya yaşam için tehlikeyi iletmek üzere kullanıcıyı kesintiye uğratmak zorundaysa — örneğin kritik bir ilaç uyarısı gönderen bir hastane portalı — bu kesinti kullanıcının tercihlerini geçersiz kılabilir. Bu istisna kasıtlı olarak dardır; rutin pazarlama mesajları, kalan süre yeterliyken gösterilen oturum zaman aşımı uyarıları ve düşük öncelikli durum güncellemeleri acil durum sayılmaz.

WCAG 2.2.4 Seviye AAA olduğundan, temel uyumluluk beyanları için zorunlu değildir, ancak tam kapsayıcılığa kendini adamış kuruluşlar için anlamlı bir standarttır. Tüm web içeriği için geçerlidir: masaüstü ve mobil web uygulamaları, JavaScript ile çalışan bildirimler kullanan tek sayfalı uygulamalar ve Web Notifications API’sinden yararlanan aşamalı web uygulamaları.

Neden Önemlidir

Bir web sayfasındaki beklenmedik kesintiler sadece rahatsız edici değildir — birçok kullanıcı için görevleri tamamlamaya yönelik ciddi bir engel ve bazı durumlarda doğrudan bir sağlık riski oluşturur.

Bilişsel ve dikkatle ilgili engelleri olan kullanıcılar — ADHD, travmatik beyin hasarı, otizm spektrum koşulları ve demans dahil — odaklarını korumak için istikrarlı, öngörülebilir bir ortama büyük ölçüde güvenirler. Ani bir bildirim veya animasyonlu uyarı, dikkatlerini tamamen dağıtabilir; bu da sosyal yardım başvurusu doldurma, tıbbi kayıt inceleme veya vergi formu doldurma gibi çok adımlı bir sürecin takibini kaybetmelerine neden olabilir. Bir kesintiden sonra yeniden odaklanmak, bu kullanıcılar için nörotipik kullanıcılara kıyasla önemli ölçüde daha uzun sürebilir ve bazı durumlarda konumlarını hiç bulamayabilirler.

Ekran okuyucu kullanıcıları dinamik kesintilerden özellikle etkilenir. Bir canlı bölge veya ARIA uyarısı DOM’a enjekte edildiğinde, NVDA, JAWS ve VoiceOver gibi ekran okuyucular bunu derhal duyuracak şekilde tasarlanmıştır; bu da yardımcı teknolojinin o anda okumakta olduğu her şeyi kesintiye uğratır. Kullanıcı önemli talimatlardan oluşan uzun bir paragrafı dinlerken, cümlenin ortasında bir pazarlama tostu tetiklenirse, ekran okuyucu paragrafı bırakır ve bildirimi duyurur. Kullanıcının ardından geri dönmesi, yerini bulması ve yeniden okuması gerekir — yalnızca klavye ve sesle gezinmekte olan biri için bu süreç göründüğünden çok daha zahmetlidir.

Anksiyete bozuklukları ve TSSB’si olan kullanıcılar, ani ve beklenmedik görsel veya işitsel değişikliklerin tetiklediği fiziksel stres tepkileri — yükselmiş kalp atış hızı, odak kaybı veya panik — yaşayabilir. Kontrolsüz kesinti ortamının öngörülemezliği, bazı web sitelerini bu kullanıcı grupları için fiilen kullanılamaz hale getirebilir.

Epilepsi veya vestibüler bozuklukları olan kullanıcılar, özellikle yanıp sönme veya hızlı hareket içeren belirli türde kesintilerden zarar görebilir. Kılavuz 2.3 nöbet risklerini özel olarak ele alırken, animasyonlu bildirim bantları ve beklenmedik şekilde beliren otomatik oynatılan video bildirimleri her iki ölçütle de kesişir.

Somut bir senaryo düşünün: ADHD’li bir kullanıcı, hesaplar arasında para transferi yapmak için çevrimiçi bankacılık portalını kullanıyor. Transfer tutarını ve hedef hesap numarasını dikkatle inceliyor. Sağ alt köşeden kayan bir promosyon teklifi bildirimi, ekran okuyucu duyurusunu ve animasyonlu bir giriş efektini tetikliyor. Kullanıcı yerini kaybediyor, animasyon odağı başka yere çektiği için kapatma düğmesini bulamıyor ve yanlış tutarı yanlışlıkla gönderiyor. Bu, uç bir varsayımsal durum değil — bu ölçütü görmezden gelmenin öngörülebilir bir sonucudur.

Engellilikten bağımsız olarak, kontrolsüz kesintiler tüm kullanıcılar için kullanılabilirliğe zarar verir, hemen çıkma oranlarını artırır (kullanıcılar kendilerini bombardımana tutan siteleri terk eder) ve kesintilerin teşvik etmeyi amaçladığı eylemlerde dönüşümü azaltabilir. SEO açısından, yüksek hemen çıkma oranları ve düşük oturum süreleri daha zayıf arama sıralaması sinyalleriyle ilişkilidir; bu da erişilebilirlik ve iş performansının burada aynı doğrultuda olduğu anlamına gelir.

İlgili Axe-core Kuralları

WCAG 2.2.4 manuel test gerektirir. axe-core dahil olmak üzere otomatik araçlar, bir sitenin kontrol edilemeyen kesintiler üretip üretmediğini güvenilir şekilde tespit edemez; çünkü bunun için aracın şunları yapması gerekir: bir kullanıcı oturumu sırasında enjekte edilen tüm dinamik içeriği gözlemlemek, her enjeksiyonun kullanıcı tarafından başlatılıp başlatılmadığını değerlendirmek, bir kapatma veya erteleme mekanizmasının mevcut ve erişilebilir olup olmadığını değerlendirmek ve içeriğin acil durum sayılıp sayılmadığını belirlemek. Bunlar, statik DOM analizinin kapsamı dışında kalan bağlamsal ve davranışsal yargılardır.

• Manuel test gerekli — Kesinti kontrolü: Test uzmanları, kullanıcı başlatması olmadan herhangi bir içerik güncellemesi, bildirim, iletişim kutusu veya medyanın başlayıp başlamadığını gözlemlemek için sayfayla belirli bir süre boyunca manuel olarak etkileşime girmelidir. Gözlemlenen her kesinti için, onu ertelemeye veya bastırmaya yönelik erişilebilir bir mekanizmanın mevcut olduğunu, bu mekanizmanın kendisinin klavye ile erişilebilir ve ekran okuyucu tarafından duyurulur olduğunu ve kullanıcı yeniden etkinleştirmedikçe kesintinin kapatıldıktan sonra tekrarlanmadığını doğrulamalıdır.
• Manuel test gerekli — Canlı bölge değerlendirmesi: aria-live, role='alert' veya role='status' kullanan sayfalar, duyuruların kullanıcı eylemleriyle (kabul edilebilir) mi yoksa zamana dayalı veya sunucu itmeli olaylarla mı (potansiyel olarak uyumsuz) tetiklendiğini belirlemek için manuel olarak incelenmelidir. Otomatik bir araç canlı bölgelerin varlığını işaretleyebilir, ancak gerçek bir kullanıcı oturumu sırasında beklenmedik kesintiler üretip üretmediklerini belirleyemez.
• Manuel test gerekli — Notification API kullanımı: Tarayıcı düzeyinde anlık bildirim göndermek için izin isteyen web uygulamaları, yalnızca tarayıcı düzeyi kontrollerine güvenmek yerine, kullanıcının bu bildirimleri bizzat web uygulamasının içinden yönetmesi veya bastırması için net bir mekanizma sunmalıdır. Bu, bildirim izin akışının ve uygulama içi bildirim tercihleri seçeneklerinin mevcudiyetinin manuel olarak incelenmesini gerektirir.

Nasıl Test Edilir

1. Temel olarak otomatik bir tarama çalıştırın. Sayfayı Chrome veya Firefox’ta açın ve axe DevTools veya Lighthouse çalıştırın. Her iki aracın da 2.2.4 için özel bir kuralı olmasa da, otomatik tarama ilgili sorunları işaretleyecektir: dinamik içerikte eksik roller, yanlış yapılandırılmış canlı bölgeler ve iletişim kutularında odak yönetimi sorunları. İşaretlenen aria-live bölgelerini veya role='alert' öğelerini not edin; bunlar için manuel takip gerekecektir.
2. Sayfayı en az iki ila üç dakika pasif olarak gözlemleyin. Hiçbir şeye tıklamadan, değişen, beliren veya kendini duyuran herhangi bir içerik için izleyin ve dinleyin. Arka planda çalışan bir ekran okuyucu (Firefox ile NVDA veya macOS’ta Safari ile VoiceOver) kullanın ve eyleminizle tetiklenmeyen duyuruları dinleyin. Her kesintiyi, zamanlamasını ve içeriğini not edin.
3. Genellikle bildirim tetikleyen etkileşimli akışları test edin. Uygulama uygunsa oturum açın, bir form veya çok adımlı bir sürece gidin ve yavaşça doldurmaya başlayın. Oluşan kesintileri not edin: oturum zaman aşımı uyarıları, sohbet davetleri, promosyon bantları, ilerleme güncellemeleri veya abonelik istemleri. Her biri için, yalnızca klavyeyi kullanarak (Tab, Escape, Enter, Space) kapatmayı veya ertelemeyi deneyin. Kapatma sonrasında odağın mantıklı bir konuma döndüğünü doğrulayın.
4. NVDA ve Firefox ile test edin. NVDA’yı etkinleştirin, Firefox’u açın ve sayfada gezinin. Mevcut okumanızı kesen herhangi bir ses çıktısına dikkatle kulak verin. Otomatik bir bildirim tetiklenirse, klavye kontrollerini kullanarak kapatmayı deneyin ve NVDA’nın kapatma onayını duyurduğunu veya odağın uygun şekilde geri döndüğünü doğrulayın.
5. JAWS ve Chrome ile test edin. JAWS ve Chrome kullanarak pasif gözlem ve etkileşimli akış testlerini tekrarlayın. JAWS ve NVDA canlı bölgeleri farklı şekilde ele aldığından, kesintilerin tutarlı şekilde duyurulduğundan ve kapatma mekanizmalarının her iki ekran okuyucuda da çalıştığından emin olmak için her ikisiyle test yapmak önemlidir.
6. iOS’ta VoiceOver ve Safari ile test edin. Bir mobil cihazda veya simülatörde, sayfada gezinmek için Safari ile VoiceOver kullanın. İçerikte gezinirken herhangi bir kesinti olup olmadığını gözlemleyin. Kapatma mekanizmasını dokunma hareketleriyle (etkinleştirmek için çift dokunma) test edin ve odağın anlamlı bir konuma döndüğünü doğrulayın.
7. Bir bildirim tercih ayarı olup olmadığını kontrol edin. Uygulama içinde bir kullanıcı profili, ayarlar paneli veya erişilebilirlik tercihleri bölümü arayın. Bildirimleri küresel olarak bastırmak veya yapılandırmak için bir kontrolün mevcut olduğunu doğrulayın ve bu ayarı etkinleştirmenin sonraki bir oturum sırasında kesintilerin oluşmasını gerçekten engellediğini test edin.
8. JavaScript kaynağını veya ağ etkinliğini inceleyin. Tarayıcı Geliştirici Araçları’nda oturum sırasında Ağ ve Konsol sekmelerini gözlemleyin. DOM’a içerik enjekte eden WebSocket bağlantıları, yoklama aralıkları veya setTimeout/setInterval çağrılarını arayın. Bunların her biri potansiyel bir kesinti kaynağıdır ve kullanıcı kontrolünün uygulandığından emin olmak için izlenmelidir.

Nasıl Düzeltilir

Otomatik açılan sohbet bileşeni — Hatalı

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

Otomatik açılan sohbet bileşeni — Doğru

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

Kontrol edilemeyen pazarlama tost bildirimi — Hatalı

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

Kontrol edilemeyen pazarlama tost bildirimi — Doğru

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

Kullanıcı kontrolü olmayan oturum zaman aşımı modali — Hatalı

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

Kullanıcı kontrolü olmayan oturum zaman aşımı modali — Doğru

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

Yaygın Hatalar

• Promosyon veya düşük öncelikli mesajlarda role='alert' kullanmak. alert rolü ekran okuyuculara aciliyet sinyali verir ve okumayı anında kesintiye uğratır. Pazarlama mesajları, ipuçları ve özellik duyuruları bunun yerine role='status' veya aria-live='polite' kullanmalıdır; bunlar içeriği yalnızca ekran okuyucu mevcut çıktısını bitirdikten sonra duyurur.
• Yalnızca üzerine gelindiğinde veya odaklandığında görünen, pratikte erişilemez bir kapatma düğmesi sağlamak. Kapatma mekanizması, görünür hale gelmesi için kullanıcının fareyle üzerine gelmesini gerektiriyorsa, yalnızca klavye kullanan kullanıcılar ve ekran okuyucu kullanıcıları bunu göremez veya erişemez. Kapatma düğmesi her zaman görünür olmalı veya en azından her zaman klavye Tab sırasıyla erişilebilir olmalıdır.
• Bir bildirimi kapattıktan sonra odağı document.body’ye döndürmek. Bir bildirim veya iletişim kutusu kapatıldığında, odak anlamlı ve bağlamsal olarak uygun bir elemana — genellikle kesinti ortaya çıkmadan önce kullanıcının etkileşimde bulunduğu elemana — dönmelidir. Odağı body üzerine bırakmak, ekran okuyucu kullanıcılarını tüm sayfayı yeniden gezmeye zorlar.
• Birden fazla aria-live bölgesini aynı anda tetiklemek. Birkaç canlı bölge aynı anda güncellendiğinde, ekran okuyucular duyuruları öngörülemez şekilde sıraya alır veya düşürür. Her kesinti dikkatle yönetilmeli, aynı anda yalnızca bir canlı bölgenin tetiklenmesi sağlanmalı ve güncellemeler mümkün olduğunca toplu yapılmalıdır.
• Tarayıcının yerel bildirim izin istemini yeterli kullanıcı kontrolü olarak görmek. Web Notifications API için tarayıcı izin iletişim kutusu, uygulama düzeyinde değil, işletim sistemi düzeyinde çalışır. WCAG 2.2.4, kullanıcıların bildirimleri yalnızca tarayıcı düzeyinde siteyi engelleyerek değil, bizzat web uygulamasının içinden yönetebilmesini gerektirir.
• Her sayfa yüklemesinde kapatılmış bir bildirimi sıfırlamak. Bir kullanıcı bir bildirimi kapatır ve aynı sayfaya veya sitedeki başka bir sayfaya gittiğinde bildirim yeniden belirirse, kapatma eylemi anlamsızdır. Tercihler en azından oturum boyunca sessionStorage kullanılarak veya kalıcı olarak localStorage ya da sunucu tarafı bir tercih kullanılarak sürdürülmelidir.
• Duraklatma kontrolü olmadan dönen bantlar veya ipuçları arasında geçiş yapmak için setInterval kullanmak. Zamanlayıcıyla yenilenen dönen içerik bir kesintidir. İçerik, ekran okuyucu kullanıcısı onu okurken değişirse, duyuru yeniden başlar. Bu karuseller ve dönen bantlar bir oynat/duraklat kontrolü gerektirir ve kullanıcı onayı olmadan süresiz olarak döngüye girmemelidir.
• DOM’a, beklenmedik kaydırma sıçramalarına neden olan bir konuma bildirim enjekte etmek. Bir bildirim bandı sayfanın üst kısmına enjekte edilir ve sayfa aşağı kayarsa, kullanıcılar görsel okuma konumlarını kaybeder. Bildirimler, kullanıcının o anda görüntülediği içeriğin düzenini etkilemeyecek şekilde, genellikle sabit veya mutlak konumlandırma kullanılarak enjekte edilmelidir.
• Kısa bir otomatik kapatma zamanlayıcısının ölçütü karşıladığını varsaymak. Beş saniye sonra kaybolan bir tost, kullanıcılara anlamlı bir kontrol sunmaz — birçok kullanıcı, özellikle bilişsel engelli olanlar veya ekran okuyucu kullananlar, içeriği bu kadar hızlı okuyamaz, işleyemez veya yanıtlayamaz. Yalnızca otomatik kapatma zamanlayıcısı sağlamak ve kullanıcı kontrollü bir kapatma düğmesi sunmamak uyumsuzdur.
• Kullanıcının işletim sistemi veya tarayıcısında azaltılmış hareket veya bildirim tercihleri etkinleştirildiğinde kesinti davranışını test etmemek. Bazı kullanıcılar, azaltılmış hareket veya bastırılmış bildirimler için işletim sistemi düzeyinde tercihler ayarlar. Uygulama bu sinyallere saygı göstermeli ve geliştiriciler, animasyonlu kesintilerin uygun şekilde bastırıldığından emin olmak için prefers-reduced-motion: reduce medya sorgusu etkin durumdayken test yapmalıdır.

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

21 Haziran 2025’te Resmî Gazete’de (Sayı: 32933) yayımlanan Türkiye Cumhurbaşkanlığı Genelgesi 2025/10, Türkiye’de faaliyet gösteren geniş bir kurum yelpazesi için bağlayıcı bir web erişilebilirliği çerçevesi oluşturur. Genelge, teknik referans standardı olarak WCAG 2.2’yi benimser ve kapsanan kuruluşlar için uyumu zorunlu kılar. Genelgede açıkça kapsanan kuruluş türleri arasında kamu kurum ve kuruluşları, e-ticaret platformları, bankalar ve finansal hizmet sağlayıcıları, hastaneler ve sağlık hizmeti kuruluşları, 200.000 veya daha fazla abonesi olan telekomünikasyon şirketleri, lisanslı seyahat acenteleri, özel ulaşım şirketleri ve Millî Eğitim Bakanlığı (MoNE) izniyle faaliyet gösteren özel okullar yer alır.

WCAG 2.2.4: Kesintiler, Seviye AAA ölçütüdür; bu da, çoğu kapsanan kuruluş için 2025/10 sayılı Cumhurbaşkanlığı Genelgesi kapsamındaki temel uyumluluk gereklilikleri arasında yer almadığı anlamına gelir. Seviye A ve Seviye AA uyumunu sağlayan ve beyan eden kuruluşlar, genelgenin asgari gereklilikleriyle hukuken uyumlu kabul edilir. Ancak 2.2.4 gibi Seviye AAA ölçütleri, Türkiye pazar bağlamında önemli pratik ve itibarî ağırlık taşır.

Kapsanan kuruluş türlerinin birçoğu — özellikle hastaneler, bankalar ve kamu kurumları — bilişsel ve nörolojik durumların, anksiyete bozukluklarının ve yaşa bağlı dikkat güçlüklerinin daha yüksek oranlarda görüldüğü kullanıcı topluluklarına hizmet eder. Bu kuruluşlar için dijital arayüzlerdeki kontrolsüz kesintiler, yalnızca bir erişilebilirlik başarısızlığı değil, aynı zamanda potansiyel bir hasta güvenliği veya finansal zarar riskidir. Kritik bir form doldurma akışı sırasında kontrol edilemeyen ilaç hatırlatıcıları veya randevu bildirimleri gönderen bir hastane hasta portalı ya da işlem incelemesi sırasında bastırılamayan promosyon bantları gösteren bir bankacılık uygulaması, bu gruplardaki kullanıcılar için gerçek dünyada zarara yol açar.

Türkiye’de dijital erişilebilirlikte liderlik göstermeyi hedefleyen kuruluşlar için — özellikle gönüllü WCAG 2.2 Seviye AAA beyanları peşinde olanlar, kamu alımlarında erişilebilirlik gerekliliklerine yanıt verenler veya Avrupa Erişilebilirlik Yasası’nın (EAA) daha yüksek bir standart belirlediği Avrupa pazarlarını hedefleyenler — 2.2.4’ü uygulamak anlamlı bir ayrıştırıcıdır. Accsible overlay SDK, yapılandırılabilir bildirim yönetimi özellikleri, kullanıcı tercihlerini kalıcı kılma ve hem Türk düzenleyici beklentileriyle hem de uluslararası en iyi uygulamalarla uyumlu erişilebilirlik odaklı bileşen davranışları sağlayarak kuruluşların bu daha yüksek standartları karşılamasına destek olur.