WCAG 2.4.12: Odak Gizlenmemeli (Gelişmiş)

Bu Kuralın Anlamı

WCAG 2.4.12 — Odağın Kapanmaması (Gelişmiş) — WCAG 2.4.11’in (Odağın Kapanmaması, AA) AAA karşılığıdır. AA ölçütü, odaklanmış bir bileşenin kısmen görünür olmasına izin verirken, AAA ölçütü odaklanmış bileşenin tamamen görünür olmasını şart koşar — klavye odağı aldığında, yazar tarafından oluşturulan içerik tarafından hiçbir parçası gizlenmemelidir.

Pratikte bu, kullanıcı bir bağlantı, buton, form alanı veya özel bir bileşen gibi etkileşimli bir elemana sekmeyle geldiğinde, o elemanın tüm sınırlayıcı alanının herhangi bir sabit üst menü, sabit alt bilgi, modal örtü, çerez bildirimi, sohbet bileşeni veya yazarın sayfaya yerleştirdiği başka herhangi bir içerik tarafından kapanmaması gerektiği anlamına gelir. Kural özellikle yazar tarafından oluşturulan içeriği hedefler; W3C, odağı gösteren işaretleyiciyi kullanıcının kendisinin hareket ettirerek kapattığı içerik için açık bir istisna tanır — örneğin, kullanıcının odaklanmış elemanın önüne sürüklediği yüzen bir panel. Bu durumda sorumluluk yazara ait değildir.

2.4.12 kapsamında başarılı sayılmak için, odak alındığında odaklanmış bileşenin tamamı görünüm alanı içinde görünür olmalı ve sayfa yazarının kontrol ettiği hiçbir sabit, yapışkan veya mutlak konumlandırılmış eleman tarafından örtülmemelidir. Başarısızlık, odaklanmış elemanın görünür sınırının herhangi bir bölümünün bu tür örtüşmelerin arkasında kalmasıyla oluşur — odak halkasının ya da bileşenin kendisinin tek bir pikselinin bile kesilmesi AAA düzeyinde başarısızlık sayılır.

2.4.12’nin neyi kapsamadığını anlamak önemlidir. Belirli bir odak göstergesi stilini zorunlu kılmaz (bu, 2.4.11 ve 2.4.7 tarafından ele alınır). Odak göstergelerinin minimum bir kontrast oranına sahip olmasını gerektirmez (2.4.13 tarafından kapsanır). Özellikle, odaklanmış eleman ile sayfadaki diğer içerik arasındaki mekânsal ilişkiyi ele alır — en sık CSS’te sabit ve yapışkan konumlandırmadan kaynaklanan katmanlama sorununu hedefler.

Etkilenen HTML elemanları, odaklanabilir veya sekmeyle erişilebilir tüm elemanları içerir: <a>, <button>, <input>, <select>, <textarea>, <details>, tabindex özelliğine sahip elemanlar ve ARIA rolleriyle oluşturulmuş özel etkileşimli bileşenler. Ölçüt, iframeler, diyaloglar ve tek sayfa uygulama (SPA) rota geçişleri dahil tüm tarama bağlamlarında geçerlidir.

Neden Önemlidir

Klavye ile gezinme, çok geniş bir kullanıcı kitlesi için birincil erişim yöntemidir. ALS, multipl skleroz, serebral palsi veya tekrarlayan zorlanma yaralanmaları gibi durumlarla yaşayanlar dahil motor engeli olan kişiler, fare yerine tamamen klavye veya anahtarlama erişim cihazlarına güvenir. Ekran okuyucu kullanan kör ve az gören kullanıcılar da klavyeyle gezinir ve yardımcı teknolojileri odak konumunu sesli olarak duyursa da, gören klavye kullanıcıları sayfada yönlerini bulmak için tamamen görsel odak göstergesine bağlıdır.

Odaklanmış eleman kısmen bile kapandığında, bu kullanıcılar sinir bozucu ve potansiyel olarak yön kaybettiren bir deneyimle karşılaşır: sayfa sanki hiç odaklanmış eleman yokmuş gibi görünebilir veya kullanıcı belgede nerede olduğunu tahmin etmek zorunda kalır. AA düzeyinde (2.4.11) kısmi görünürlük tolere edilir — bileşenin en azından bir kısmı görünür kalarak bir ipucu sağlar. AAA ölçütü bu uzlaşmayı tamamen ortadan kaldırır ve kısmen gizlenmiş bir odak göstergesinin bile azalmış kontrast duyarlılığı, tünel görüşü veya ekranı taramayı zorlaştıran bilişsel durumları olan kullanıcılar tarafından gözden kaçırılabileceğini kabul eder.

Somut bir senaryo düşünün: Türkçe bir e-ticaret sitesi, görünüm alanının üst kısmında 80px yüksekliğinde sabit bir gezinme çubuğu ve alt kısmında 60px yüksekliğinde yapışkan bir çerez onay bandı kullanıyor. Ürün kartları arasında gezinmek için Sekme tuşuna basan bir kullanıcı, odaklanmış kartın üst veya alt kenarının — odak halkası dahil — bu sabit yüzeylerden birinin altına kaydığını görebilir. WCAG 2.4.11 (AA) kapsamında, kartın herhangi bir kısmı hâlâ görünürse site başarılı sayılır. 2.4.12 (AAA) kapsamında ise kartın tamamının tamamen görünür olması gerekir. Bu ayrım anlamlıdır: kısmen gizlenmiş bir buton etiketi ile kısmen gizlenmiş bir odak halkasının birleşimi, az gören bir kullanıcının hangi elemanın etkin olduğunu veya hangi işlemi gerçekleştireceğini gerçekten belirleyememesine yol açabilir.

Dünya Sağlık Örgütü’ne göre, dünya genelinde yaklaşık 2,2 milyar kişinin bir tür görme bozukluğu vardır ve motor engeller yüz milyonlarca kişiyi daha etkiler. Klavye erişilebilirliğindeki iyileştirmeler yalnızca bu gruplara değil, aynı zamanda hız için klavye ile gezinmeyi tercih eden ileri düzey kullanıcılara, işaretleme aygıtı olmayan cihazlardaki kullanıcılara ve ince motor kontrolünün geçici olarak bozulduğu durumlarda bulunan kullanıcılara da fayda sağlar.

Engellilik erişiminin ötesinde, tamamen görünür odak genel kullanılabilirliği artırır ve destek maliyetlerini azaltır. Tüm kullanıcılar — engeli olmayanlar dahil — odak konumunu net bir şekilde takip edebildiğinde, form doldurma oranları artar ve hata oranları düşer. Türk pazarını hedefleyen siteler için AAA uyumunu göstermek, olgun bir erişilebilirlik programına işaret eder ve hem kullanıcılar hem de kurumsal tedarik ekipleri nezdinde güven oluşturur.

İlgili Axe-core Kuralları

WCAG 2.4.12, manuel test gerektiren bir ölçüt olarak sınıflandırılır ve WCAG 2.2 eklerinin bir parçasıdır. Bu ihlali güvenilir şekilde tespit edebilen tam otomatik bir axe-core kuralı yoktur ve bunun nedenini anlamak, test süreçlerini oluşturan ekipler için önemlidir.

• Manuel inceleme — focus-not-obscured-enhanced (otomatik kural yok): axe-core gibi otomatik erişilebilirlik tarayıcıları statik DOM üzerinde veya işlenmiş durumun bir anlık görüntüsü üzerinde çalışır. Odaklanmış bir elemanın kapanıp kapanmadığını tespit etmek için: (1) her etkileşimli elemanda sırayla klavye odağını simüle etmek, (2) odak kaynaklı kaydırmadan sonra elemanın sınırlayıcı dikdörtgenini hesaplamak, (3) tüm sabit ve yapışkan konumlandırılmış elemanları ve bunların sınırlayıcı dikdörtgenlerini belirlemek ve (4) geometrik örtüşmeyi test etmek gerekir. Kısmi otomasyon teorik olarak mümkün olsa da, kaydırma davranışının dinamik yapısı, CSS scroll-padding, yumuşak kaydırma ve JavaScript ile yönetilen odak yönetimi bunu pratikte oldukça güvenilmez kılar. Bir görünüm alanı boyutunda mükemmel şekilde görünür olan odaklanmış bir eleman, başka bir boyutta tamamen kapanmış olabilir. axe-core bu ölçütü insan yargısı gerektiren bir madde olarak işaretler ve bulguları otomatik ihlal yerine “inceleme gerekli” olarak sınıflandırır. Test uzmanları, her etkileşimli elemanı sekmeyle tek tek dolaşmalı ve her ilgili görünüm alanı genişliğinde tam görünürlüğü görsel olarak doğrulamalıdır.
• scrollable-region-focusable (axe kuralı): Doğrudan 2.4.12 ile eşleştirilmemiş olsa da, bu axe kuralı, kaydırılabilir bölgeler içinde odaklanabilir olup doğru şekilde görünüm alanına kaymayabilecek elemanları işaretler. Bu, odaklanmış elemanın sabit üstbilgiler veya altbilgiler tarafından kapanmasına yol açabilecek kaydırma yönetimi sorunlarını gösteren ilgili bir sinyaldir — 2.4.12 için en yaygın başarısızlık biçimi budur.

Otomatik araçlar 2.4.12 ihlallerini güvenilir şekilde yakalayamadığı için, kurumların QA süreçlerine manuel klavye ile gezinme senaryolarını dahil etmeleri gerekir; ideal olarak birden fazla görünüm alanı boyutunda ve tüm kalıcı arayüz katmanları (gezinti çubukları, sohbet bileşenleri, çerez bildirimleri, GDPR uyarıları) etkin durumdayken.

Nasıl Test Edilir

1. Otomatik temel tarama: Sayfada axe DevTools veya Lighthouse çalıştırarak scrollable-region-focusable ihlalleri veya CSS taşma (overflow) sorunları gibi ilgili problemleri tespit edin. Bu bulgular doğrudan 2.4.12 ihlali olmasa da, odak kapanması sorunlarına en yatkın sayfa alanlarını gösterir. axe DevTools’ta WCAG 2.2 ölçütlerine göre filtreleyin ve odak görünürlüğüyle ilgili “inceleme gerekli” öğeleri gözden geçirin.
2. Tüm kalıcı örtüşen içeriği belirleyin: Klavye testi öncesinde, sayfadaki position: fixed veya position: sticky kullanan tüm elemanları görsel olarak listeleyin — tipik olarak gezinme çubukları, çerez bildirimleri, sohbet bileşenleri, yüzen eylem butonları ve alt araç çubukları. Görünüm alanının hangi bölgelerini kapladıklarını bilmek için yüksekliklerini ve konumlarını not edin.
3. Klavye ile gezinme senaryosu: Sayfanın üstünden (veya ilk modal kapatıldıktan) başlayarak, odağı her etkileşimli elemana taşımak için Sekme tuşuna art arda basın. Her odak duraklamasında, odaklanmış elemanın tamamının — görünür odak göstergesi (çerçeve veya halka) dahil — kapanmamış görünüm alanı içinde tamamen yer aldığını doğrulayın. Kısmi görünürlüğü kabul etmeyin. Elemanın veya odak halkasının herhangi bir kısmı sabit bir elemanın arkasında kaybolursa, bunu 2.4.12 başarısızlığı olarak kaydedin.
4. Ters yönde gezinme: Senaryoyu Shift+Tab kullanarak geriye doğru gezinerek tekrarlayın. Sabit altbilgiler, yalnızca ileri yönde yapılan testlerde gözden kaçabilir ancak ters sekme sırasında elemanları kapatabilir.
5. NVDA + Firefox ile ekran okuyucu testi: NVDA’yı açın, Firefox’u başlatın ve Sekme ile gezin. NVDA bir elemanda odağı duyurduğunda, elemanın tamamen görünür olduğunu görsel olarak doğrulayın. NVDA’nın odak modu, elemanları sabit katmanların altından otomatik olarak kaydırmaz; bu nedenle ihlaller, tarayıcı varsayılan davranışından farklı olabilir.
6. VoiceOver + Safari (macOS/iOS) ile ekran okuyucu testi: VoiceOver’ı etkinleştirin ve gezinmek için Sekme (veya iOS’ta kaydırma hareketi) kullanın. Safari’nin kaydırma yönetimi bazen Chromium’dan farklıdır ve Chrome’da görülmeyen kapanmış odak durumlarını ortaya çıkarabilir.
7. Duyarlı görünüm alanı testi: Klavye senaryosunu yaygın kırılma noktalarında tekrarlayın — 320px, 768px, 1024px ve 1440px genişlikte. Yapışkan elemanlar genellikle farklı kırılma noktalarında daha uzun hale gelir veya yeniden konumlanır; bu da riskli bölgeleri değiştirir.
8. Kullanıcı etkileşimlerinden sonra test: Açılır menüleri açın, akordeonları genişletin, modalları tetikleyin ve tek sayfa uygulamalarda yeni rotalara gidin. Her durum değişikliğinden sonra Sekme ile gezinmeye devam edin ve odak görünürlüğünü yeniden doğrulayın; çünkü dinamik içerik genellikle yeni sabit örtüşmeler oluşturur.

Nasıl Düzeltilir

Yapışkan Üstbilginin Odaklanmış Bağlantıları Kapatması — Hatalı

<!-- Kaydırma telafisi olmayan sabit üstbilgi -->
<header style='position:fixed; top:0; height:80px; background:#fff; width:100%;'>
  <nav>...</nav>
</header>

<main>
  <!-- Sekme, main'in üstüne yakın bu bağlantıya geldiğinde üstbilgi bunu kapatır -->
  <a href='/products'>View all products</a>
</main>

Yapışkan Üstbilginin Odaklanmış Bağlantıları Kapatması — Doğru

<!-- scroll-padding-top, odaklanmış elemanların sabit üstbilginin altından kaydırılmasını sağlar -->
<style>
  html {
    /* Bu değeri sabit üstbilginizin yüksekliğiyle eşleştirin */
    scroll-padding-top: 88px; /* 80px üstbilgi + 8px boşluk payı */
  }
</style>

<header style='position:fixed; top:0; height:80px; background:#fff; width:100%;'>
  <nav>...</nav>
</header>

<main style='margin-top:80px;'>
  <!-- Odak artık elemanı üstbilginin tamamen altına kaydırır -->
  <a href='/products'>View all products</a>
</main>

Çerez Bandının Görünüm Alanının Altındaki Etkileşimli Elemanları Kapatması — Hatalı

<!-- Kaydırma telafisi olmayan, alta sabitlenmiş çerez bandı -->
<div id='cookie-banner' style='position:fixed; bottom:0; height:72px; width:100%; background:#222;'>
  <button>Accept All</button>
  <button>Manage Preferences</button>
</div>

<footer>
  <!-- Sayfanın altındaki bu bağlantılar çerez bandı tarafından kapatılır -->
  <a href='/privacy'>Privacy Policy</a>
  <a href='/terms'>Terms of Service</a>
</footer>

Çerez Bandının Görünüm Alanının Altındaki Etkileşimli Elemanları Kapatması — Doğru

<!-- Bant yüksekliğini telafi etmek için scroll-padding-bottom ve body padding ekleyin -->
<style>
  html {
    scroll-padding-bottom: 80px; /* 72px bant + 8px boşluk payı */
  }
  body {
    padding-bottom: 80px; /* İçeriğin kalıcı olarak bandın altında kalmasını önleyin */
  }
</style>

<div id='cookie-banner' style='position:fixed; bottom:0; height:72px; width:100%; background:#222;'>
  <button>Accept All</button>
  <button>Manage Preferences</button>
</div>

<footer>
  <!-- Bağlantılar artık tamamen kapanmamış görünüm alanına kayar -->
  <a href='/privacy'>Privacy Policy</a>
  <a href='/terms'>Terms of Service</a>
</footer>

JavaScript Odak Yönetiminin Sabit Katmanları Hesaba Katmaması — Hatalı

<!-- SPA rota değişimi: odak başlığa taşınır ancak scrollIntoView üstbilgiyi yok sayar -->
<script>
function navigateTo(section) {
  const heading = document.querySelector('#' + section + ' h2');
  heading.setAttribute('tabindex', '-1');
  heading.focus();
  // Ofset olmadan scrollIntoView — başlık sabit üstbilginin arkasına kayar
  heading.scrollIntoView({ behavior: 'smooth', block: 'start' });
}
</script>

JavaScript Odak Yönetiminin Sabit Katmanları Hesaba Katmaması — Doğru

<!-- Hedef elemanda scroll-margin-top kullanın veya scrollY'yi elle ofsetleyin -->
<style>
  .focus-target {
    /* scroll-margin-top, bu elemanın kaydırma konumunu üstten ofsetler */
    scroll-margin-top: 96px;
  }
</style>

<script>
function navigateTo(section) {
  const heading = document.querySelector('#' + section + ' h2');
  heading.setAttribute('tabindex', '-1');
  // Elemandaki scroll-margin-top görsel ofseti otomatik olarak yönetir
  heading.classList.add('focus-target');
  heading.focus();
  // scrollIntoView artık scroll-margin-top değerine uyar ve sabit üstbilgiyi temizler
  heading.scrollIntoView({ behavior: 'smooth', block: 'start' });
}
</script>

Yaygın Hatalar

• scroll-padding-top özelliğini body yerine html üzerinde ayarlamak: CSS scroll-padding özelliği, kaydırma konteynerine uygulanmalıdır. Tam sayfa kaydırmada kaydırma konteyneri body değil, html elemanıdır. Çoğu tarayıcıda bu özelliği body üzerinde kullanmak hiçbir etki yaratmaz ve en yaygın uygulama hatalarından biridir.
• scroll-padding-top için tüm kırılma noktalarında gerçek üstbilgi yüksekliğiyle uyuşmayan sabit piksel değeri kullanmak: Üstbilgi mobilde daha küçük bir yüksekliğe çöktüğünde veya masaüstünde ikincil bir gezinme çubuğunu içerecek şekilde genişlediğinde, statik ofset yanlış hale gelir. Değeri senkron tutmak için JavaScript ile güncellenen CSS özel özelliklerini kullanın veya göreli birimlerle calc() kullanın.
• Sayfa içi bağlantı hedeflerinde scroll-margin-top özelliğini unutmak: Küresel scroll-padding-top Sekme ile gezinme için doğru olsa bile, programatik olarak odak alan bağlantı hedefleri (örneğin, atla bağlantıları, SPA’lerde hash navigasyonu) üzerinde scroll-margin-top ayarlanmadıkça yine de üstbilginin altına gelebilir.
• Çerez bandını kapattıktan sonra yeniden test etmemek: Birçok ekip klavye ile gezinmeyi yalnızca çerez bandını kabul ettikten sonra test eder. Bant görünüm alanının altını kapladığı için, alta sabitlenmiş odaklanabilir elemanlar yalnızca bant etkin durumdayken kapanabilir. Her zaman tüm kalıcı arayüz katmanları tam görüntülenmiş durumdayken test yapın.
• Yalnızca tek bir görünüm alanı genişliğinde test yapmak: Yapışkan elemanlar genellikle farklı kırılma noktalarında yükseklik değiştirir, görünür hale gelir veya tamamen kaybolur. 375px’de görülen bir başarısızlık 1440px’de ortaya çıkmayabilir ve tersi de geçerlidir. Yalnızca tek boyutta test yapmak, gerçek dünyadaki ihlallerin önemli bir kısmını kaçırır.
• Odak göstergelerini kesmek için üst kapsayıcıda overflow: hidden kullanmak: Bir kart bileşeni veya kapsayıcı overflow: hidden kullandığında, alt elemanlardaki tarayıcı varsayılanı odak çerçevesi kapsayıcı sınırında kesilir. Bu, odak durumunun DevTools eleman incelemesinde tamamen görünür görünmesine rağmen kullanıcı için görsel olarak kesilmiş olmasına yol açabilir.
• Ekran okuyucuların kaydırmayı otomatik yönettiğini varsayarak görsel testin gereksiz olduğunu düşünmek: Ekran okuyucular odaklanmış elemanı sesli olarak duyursa da, ekran büyütme araçları kullananlar dahil gören klavye kullanıcıları tamamen görsel konuma güvenir. Görsel olarak kapanmış bir odak durumu, ekran okuyucu davranışından bağımsız olarak gerçek bir başarısızlıktır.
• Modal diyalogları ve çekmece (drawer) örtülerini test etmemek: Bir modal açıldığında ve odak içine taşındığında, arka plan veya modalın kendi çerçevesi, diyalog içindeki ilk odaklanmış elemanı kapatabilir. Bu, özellikle yandan veya alttan animasyonla gelen çekmece tarzı panellerde yaygındır.
• Canlı sohbet balonları ve geçiş reklam bantları gibi üçüncü taraf bileşenleri göz ardı etmek: Yüzen sohbet bileşenleri (örneğin Intercom, Zendesk) ve etiket yöneticileri tarafından enjekte edilen sabit promosyon bantları, yazar tarafından oluşturulan içeriktir ve bu ölçütün kapsamına girer. Ekipler bunları genellikle ana kod tabanı dışında yönetildikleri için gözden kaçırır.
• Yalnızca otomatik erişilebilirlik taramalarına güvenip bileti kapatmak: 2.4.12 manuel test gerektirdiğinden, temiz bir axe-core taraması uyumu doğrulamaz. Erişilebilirlik biletlerini yalnızca otomatik sonuçlara dayanarak kapatmak, bu ölçütü sürekli olarak gözden kaçıracaktır.

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

Türkiye’nin 2025/10 sayılı Cumhurbaşkanlığı Genelgesi, 21 Haziran 2025 tarihli ve 32933 sayılı Resmî Gazete’de yayımlanarak Türkiye’de faaliyet gösteren geniş bir kurum yelpazesi için bağlayıcı web ve mobil erişilebilirlik gereklilikleri getirmiştir. Genelge, temel uyum standardı olarak WCAG 2.1 Seviye AA’yı benimser; bu da WCAG 2.4.12’nin — WCAG 2.2 AAA ölçütü olarak — mevcut düzenleme kapsamında doğrudan zorunlu olmadığı anlamına gelir. Ancak, Türkiye’nin erişilebilirlik çerçevesiyle ilişkisi birkaç açıdan önemlidir.

2025/10 sayılı Cumhurbaşkanlığı Genelgesi kapsamındaki kurumlar; tüm düzeylerdeki kamu kurum ve kuruluşları, e-ticaret platformları, bankalar ve finansal hizmet sağlayıcıları, hastaneler ve sağlık kuruluşları, 200.000 veya daha fazla abonesi olan telekomünikasyon şirketleri, seyahat acenteleri, özel ulaşım şirketleri ve Millî Eğitim Bakanlığı (MEB) tarafından yetkilendirilmiş özel okulları içerir. Bu kurumların tamamı için WCAG 2.1 AA uyumuna ulaşmak yasal bir yükümlülüktür ve genelgenin ilgili denetim otoriteleri tarafından yürütülecek denetim mekanizmalarıyla uygulanması beklenmektedir.

Genelge AAA uyumunu zorunlu kılmasa da, düzenlenen sektörlerdeki kurumların WCAG 2.4.12 uyumunu hedeflemeleri için güçlü pratik gerekçeler vardır. Birincisi, Türkiye’deki düzenleyici ortam gelişmektedir: genelge, önceki rehberliklere kıyasla erişilebilirlik uygulamasında önemli bir sıkılaşmayı temsil eder ve gelecekteki revizyonlar WCAG 2.2’yi benimseyebilir veya uyum seviyesini yükseltebilir. Bugünden AAA uygulamaları geliştiren kurumlar, düzenleyici değişikliklere daha iyi hazırlanmış olacaktır. İkincisi, kamu alımları ve AB pazarına erişim süreçleri giderek daha fazla, gelişmiş erişilebilirlik programlarını belgeleyebilen tedarikçileri tercih etmektedir ve AAA uyum dokümantasyonu rekabetçi bir farklılaştırıcı sağlar.

Üçüncüsü ve WCAG 2.4.12 ile en doğrudan ilgili olan nokta, bu ölçütün Türkiye’deki yardımcı teknoloji kullanıcılarını orantısız şekilde etkileyen bir başarısızlık biçimini ele almasıdır — motor, görsel ve bilişsel engeller birlikte değerlendirildiğinde birkaç milyon kişi olduğu tahmin edilen bir nüfus. Sabit gezinme çerçevelerine ve kalıcı bildirim katmanlarına yoğun şekilde dayanan bankalar, hastaneler ve e-devlet portalları, odak kapanması hatalarının en sık görüldüğü sitelerdir. Tam WCAG 2.4.12 uyumuna yatırım yapmak, tüm kullanıcılara hizmet etme konusunda gerçek bir kararlılık gösterir, genelgenin lafzı henüz bunu zorunlu kılmasa bile ruhuyla uyum sağlar ve Türkiye’deki uygulama olgunlaştıkça hukuki ve itibar riskini azaltır.

Accsible overlay SDK’sını kullanan kurumlar için platform, klavye odak yollarını denetlemek ve yapışkan konumlandırma çatışmalarını tespit etmek için araçlar sunar; böylece hem 2025/10 sayılı Cumhurbaşkanlığı Genelgesi’nin zorunlu AA gerekliliklerini hem de WCAG 2.4.12 gibi isteğe bağlı AAA iyileştirmelerini destekler.