WCAG 2.4.11: Odak Gizlenmemeli (Asgari)

Bu Kuralın Anlamı

WCAG 2.4.11 Odak Gizlenmemiş (Asgari), WCAG 2.2 ile getirilen Seviye AA ölçütüdür ve yaygın ama ciddi bir erişilebilirlik sorununu ele alır: odaklanmış bir öğenin sayfadaki başka bir içerik katmanının arkasında tamamen gizlenmesi. Ölçüt, herhangi bir kullanıcı arayüzü bileşeni klavye odağı aldığında, bu bileşenin yazar tarafından oluşturulan içerik tarafından tamamen gizlenmemesi gerektiğini belirtir.

Buradaki kilit kelime tamamen. WCAG 2.4.11 asgari eşiği belirler — yalnızca odaklanmış öğenin bir kısmının görünür kalmasını şart koşar. Eğer yapışkan bir gezinme çubuğu odaklanmış bir düğmenin üst yarısının üzerine biniyor, ancak alt yarısı hâlâ görünürse, bu teknik olarak 2.4.11’i geçer. Daha katı olan eşlik eden ölçüt, Seviye AAA’daki WCAG 2.4.12 Odak Gizlenmemiş (Gelişmiş), odaklanmış bileşenin yazar tarafından oluşturulan içerik tarafından hiç — kısmen bile — gizlenmemesini şart koşarak daha ileri gider.

Bu sorundan en sık sorumlu olan yazar tarafından oluşturulmuş içerik türleri arasında yapışkan veya sabit konumlu üstbilgiler ve altbilgiler, çerez onay bantları, sohbet destek bileşenleri, bildirim tostları, modal örtüler, kayan eylem düğmeleri ve mobil uyumlu düzenlerdeki alt gezinme çubukları bulunur. Bu öğeler, position: fixed, position: sticky veya yüksek z-index değerleri gibi CSS özellikleri kullanılarak oluşturulur; bu da onların normal belge akışının üzerinde “yüzmesine” ve odak alan etkileşimli öğelerin üzerini potansiyel olarak kaplamasına neden olur.

Geçer, bir klavye kullanıcısı etkileşimli öğeler arasında sekme ile dolaşırken, odaklanmış her öğenin görsel göstergesinin en az bir kısmının ekranda her zaman görünür olması anlamına gelir — yapışkan bir arayüz öğesi bunun bir kısmının üzerine binse bile. Kalır, odaklanmış bir öğe yazar tarafından oluşturulan bir katmanın altında tamamen gizlendiğinde, yani kullanıcının odağın şu anda nerede olduğuna dair hiçbir görsel ipucuna sahip olmadığı durumda söz konusudur. Tarayıcı tarafından oluşturulan içerik, örneğin tarayıcının kendi araç çubuğu, yazar tarafından oluşturulan içerik sayılmaz ve bu nedenle bu ölçütün kapsamı dışındadır. Benzer şekilde, kullanıcının kendisinin yeniden konumlandırdığı içerik (kullanıcı tarafından sürüklenebilen bir panel gibi) de kapsam dışıdır.

Bu ölçüt, varsayılan olarak klavye ile odaklanabilir olan veya tabindex aracılığıyla odaklanabilir hâle getirilen tüm etkileşimli HTML öğeleri için geçerlidir; buna <a>, <button>, <input>, <select>, <textarea> ve tabindex='0' veya pozitif tabindex değerlerine sahip öğeler dahildir.

Neden Önemlidir

Klavye ile gezinme, birden fazla kullanıcı grubu için erişilebilirliğin temelidir. Fare kullanamayan motor engelli kişiler, bir web sayfasında gezinmek için tamamen klavyelere, anahtarlara veya nefesle çalışan kontrol cihazlarına güvenir. Kör kişiler ekran okuyucuları klavyelerle birlikte kullanır. Ekran okuyucu kullanmadan klavye ile gezinme yapan az gören kişiler, nerede olduklarını anlamak için büyük ölçüde görünür odak göstergesine dayanır. Odaklanmış öğe yapışkan bir üstbilginin veya kayan bir bileşenin arkasına gizlendiğinde, bu kullanıcılar fiilen kaybolur — Tab tuşuna tekrar tekrar basmak, konumlarını tahmin etmek veya görevi tamamen bırakmak zorunda kalırlar.

Somut bir gerçek dünya senaryosunu düşünün: Sınırlı el hareketliliğine sahip tekerlekli sandalye kullanan bir kişi, bir Türk hava yolu şirketinin web sitesinde uçuş rezervasyon formunu dolduruyor. Form alanları arasında ilerlemek için Tab tuşunu kullanıyor. Sayfanın görünüm alanının altında yapışkan bir çerez onay bandı var. Kullanıcı son onay onay kutusuna sekme ile geçtiğinde, onay kutusu çerez bandının altında tamamen render ediliyor. Kullanıcının onay kutusunun odakta olduğuna dair hiçbir görsel göstergesi yok. Tab tuşuna basmasının işe yarayıp yaramadığını, tekrar Tab’a basması gerekip gerekmediğini veya onay kutusunun zorunlu olup olmadığını anlayamıyor. Bu kafa karışıklığı formun yarım bırakılmasına, kaçırılan gönderimlere veya istenmeyen eylemlere yol açan tekrarlanan tuş vuruşlarına neden olabilir.

Etkisi engelli kullanıcıların ötesine uzanır. Hız için klavye ile gezinmeyi tercih eden güç kullanıcılar — geliştiriciler, veri girişi profesyonelleri ve yetkin kullanıcılar — da net odak görünürlüğünden fayda sağlar. Dünya Sağlık Örgütü’ne göre, dünya genelinde yaklaşık 1.3 milyar insan bir tür engellilikle yaşamaktadır ve bunların önemli bir kısmı yardımcı teknolojilere veya klavye ile gezinmeye dayanır. Türkiye özelinde ise Türkiye İstatistik Kurumu (TÜİK), nüfusun yaklaşık %12.7’sinin bir tür engelliliğe sahip olduğunu bildirmektedir; bu da dijital platformlarda iyileştirilmiş odak yönetiminden doğrudan fayda görebilecek yaklaşık 10 milyon kişi anlamına gelir.

İş açısından bakıldığında, gizlenmiş odak göstergeleri görev terk oranlarını artırır, dönüşümleri azaltır ve kuruluşları hukuki ve düzenleyici risklere maruz bırakır. Bu ölçütü karşılamayan siteler, Türk mevzuatı kapsamında zorunlu olan erişilebilirlik denetimlerinde başarısız olma olasılığı yüksek olan sitelerdir ve bu da resmi Erişilebilirlik Logosu’nu alma veya koruma yeteneklerini tehlikeye atar.

İlgili Axe-core Kuralları

WCAG 2.4.11, axe-core içinde manuel test gerektiren bir ölçüt olarak sınıflandırılır. Bu ihlali doğrudan tespit eden otomatik bir axe-core kuralı yoktur. Otomatik araçların bu sorunu neden güvenilir şekilde işaretleyemediğini anlamak, ekiplerin daha iyi manuel test süreçleri oluşturmasına yardımcı olur.

• Manuel Test Gerekli — Sabit Konumlandırma Nedeniyle Gizlenen Odak: Otomatik araçlar, odaklanmış bir öğenin görsel olarak gizlenip gizlenmediğini tespit edemez; çünkü bunun belirlenmesi için sayfanın render edilmesi, çalışma zamanında tüm sabit veya yapışkan öğelerin sınırlayıcı dikdörtgenlerinin hesaplanması ve odak anında mevcut odaklanmış öğenin sınırlayıcı dikdörtgeniyle karşılaştırılması gerekir. Görünüm alanı boyutları, kaydırma konumu ve sayfanın dinamik durumu (örneğin bir çerez bandının daha önce kapatılıp kapatılmadığı) sonuca etki eder. Hiçbir statik analiz veya DOM incelemesi, tüm olası durumlar için bu görsel hesaplamayı güvenilir şekilde çoğaltamaz. Axe-core bu ölçütü manuel olarak işaretler; çünkü sayfada gerçekten sekme ile dolaşarak odaklanmış bileşenlerin üst üste binen katmanların arkasında kaybolup kaybolmadığını gözlemleyecek bir insan testçiye — veya gelişmiş bir görsel regresyon aracına — ihtiyaç vardır.
• Manuel Test Gerekli — Dinamik Örtü İçeriği: Birçok gizleyici öğe, ilk sayfa yüklemesinden sonra JavaScript aracılığıyla dinamik olarak eklenir — üçüncü taraf sohbet bileşenleri, GDPR uyum bantları, tanıtım pop-in’leri ve kayan gezinme menüleri gibi. İlk DOM anlık görüntüsünü analiz eden otomatik tarayıcılar bu öğeleri hiç yakalamayabilir veya kullanıcı deneyimini yansıtmayan kapalı ya da gizli bir durumda yakalayabilir. Sayfanın tam olarak render edilmiş, dinamik hâliyle etkileşime giren bir klavye kullanıcısı tarafından yapılan manuel test, bu senaryoları tespit etmenin tek güvenilir yoludur.

Nasıl Test Edilir

1. Önce otomatik bir erişilebilirlik taraması çalıştırın. Sayfadaki otomatik olarak tespit edilebilir sorunları belirlemek için axe DevTools (tarayıcı eklentisi), Chrome DevTools içindeki Lighthouse veya CI’ye entegre bir axe-core taraması kullanın. 2.4.11’in kendisi manuel doğrulama gerektirse de, otomatik bir tarama eksik odak göstergeleri (2.4.7) veya üst üste binen öğelere işaret eden hatalı z-index katmanlaması gibi ilgili sorunları ortaya çıkarabilir. Manuel testlere başlamadan önce potansiyel olarak sorunlu olarak işaretlenen tüm öğeleri not edin.
2. Sayfadaki tüm sabit ve yapışkan öğeleri belirleyin. Tarayıcı Geliştirici Araçları’nı açın ve sayfanın CSS’ini inceleyin. position: fixed veya position: sticky kullanan öğeleri arayın. Ayrıca yüksek z-index değerlerine (örneğin 100 veya üzeri) sahip öğeleri kontrol edin. Bu öğelerin her birini — üstbilgiler, altbilgiler, bantlar, sohbet bileşenleri, çerez bildirimleri — belgeleyin; çünkü odaklanmış bileşenleri gizleme olasılığı en yüksek adaylar bunlardır. Görünüm alanı boyutlarını simüle etmek için tarayıcı penceresini yeniden boyutlandırın; tablet ve mobil genişlikler dâhil, çünkü yapışkan/sabit öğeler genellikle kırılma noktalarına göre farklı davranır.
3. Tam bir klavye sekme geçişi yapın. Odağın sayfanın en üstünden başlamasını sağlamak için herhangi bir etkileşimli öğenin dışına tıklayın, ardından odaklanabilir her öğe arasında dolaşmak için Tab tuşuna art arda basın. Her öğe odağı aldığında dikkatle izleyin. Özellikle görünüm alanının üst veya altına yakın görünen öğelere dikkat edin; çünkü sabit üstbilgiler veya altbilgiler en çok buralarda üst üste binebilir. Herhangi bir noktada görünür odak halkası veya vurgulanan öğe sabit bir katmanın arkasında tamamen kaybolursa, bu 2.4.11’in ihlalidir. Kaydırma konumu ve düzen farklı olabileceğinden Shift+Tab kullanarak ters yönde de dolaşın.
4. NVDA ve Firefox ile test edin. NVDA’yı (Windows için ücretsiz, açık kaynak ekran okuyucu) açın ve Firefox’u başlatın. NVDA’nın gezinme modunu etkinleştirin ve sayfada ilerlemek için Tab tuşunu kullanın. NVDA her odaklanmış öğeyi sesli olarak duyururken, aynı zamanda ekranı görsel olarak da gözlemleyin. NVDA’nın odağı duyurduğu, ancak gizleyici içerik nedeniyle hiçbir görsel odak göstergesinin görünmediği öğeleri not edin. Bu kombinasyon Türkiye’de ve dünya genelinde yaygın olarak kullanılır ve önemli bir yardımcı teknoloji eşleşmesini temsil eder.
5. macOS/iOS’ta VoiceOver ve Safari ile test edin. VoiceOver’ı etkinleştirin (Mac’te Command+F5) ve odaklanabilir öğeler arasında dolaşmak için Tab veya VoiceOver’ın gezinme hareketlerini kullanın. iOS’ta kaydırma hareketlerini kullanın. Özellikle mobilde, gezinme çubukları ve çerez bantlarının görünüm alanının daha büyük bir bölümünü kaplayabildiği durumlarda, odaklanmış öğelerin görsel olarak mevcut olduğundan ve sabit arayüz katmanlarının altında gizlenmediğinden emin olun.
6. JAWS ve Chrome ile test edin. JAWS’ı (Job Access With Speech) açın ve Chrome’u kullanın. Tüm etkileşimli öğeler arasında sekme ile dolaşın ve JAWS imlecinin sabit bir katmanın altında görsel olarak gizlenmiş bir öğeye geçtiği herhangi bir anı izleyin. JAWS, kurumsal ve kamu kurumlarında yaygın olarak kullanılır; bu da bu kombinasyonu kamu sektörü ve kurumsal web sitelerini test etmek için özellikle önemli kılar.
7. Düzeni değiştiren kullanıcı etkileşimlerinden sonra test edin. Çerez bantlarını kapatın, gezinme menülerini açıp kapatın, bildirim tostlarını tetikleyin ve sohbet bileşenlerini açın. Her durum değişikliğinden sonra, yeni düzenin odak gizlenmesinin yeni örneklerini oluşturmadığından emin olmak için baştan bir Tab geçişi yapın. Dinamik içerik, yalnızca kullanıcı etkileşiminden sonra ortaya çıkan 2.4.11 ihlallerinin yaygın bir kaynağıdır.
8. Birden fazla kaydırma konumunda test edin. Uzun bir sayfanın ortasına veya altına kaydırın, ardından o bölgede bulunan öğeler arasında sekme ile dolaşın. Sabit üstbilgiler, sayfanın üstüne yakın öğeleri gizlemeyebilir; ancak kullanıcı aşağı kaydırdıkça görünüm alanının üst kenarında beliren öğeleri kaplayabilir. Hiçbir kaydırma konumu ve odaklanmış öğe kombinasyonunun, tamamen görsel gizlenmeyle sonuçlanmadığını doğrulayın.

Nasıl Düzeltilir

Yapışkan Üstbilginin Odaklanmış Bağlantıların Üzerine Binmesi — Hatalı

<!-- Kaydırma ofseti dikkate alınmadan tanımlanmış yapışkan üstbilgi -->
<header style='position: fixed; top: 0; left: 0; width: 100%; height: 60px; z-index: 1000; background: white;'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- scroll-margin-top ayarlı değil; main'in üstündeki odaklanmış bağlantı üstbilginin altına kayıyor -->
  <a href='/section-one'>Go to Section One</a>
  <a href='/section-two'>Go to Section Two</a>
</main>

Yapışkan Üstbilginin Odaklanmış Bağlantıların Üzerine Binmesi — Doğru

<!-- Tüm odaklanabilir öğelere scroll-margin-top uygulanan sabit üstbilgi -->
<header class='site-header'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- scroll-margin-top, tarayıcının öğeyi görünüm alanına yeterli boşlukla
       kaydırmasını sağlar; böylece sabit üstbilgi onu kapatmaz -->
  <a href='/section-one' class='content-link'>Go to Section One</a>
  <a href='/section-two' class='content-link'>Go to Section Two</a>
</main>

<!-- Stil sayfanızda: -->
<!-- .site-header { position: fixed; top: 0; height: 60px; z-index: 1000; } -->
<!-- * { scroll-margin-top: 70px; } -->
<!-- 70px (üstbilgi yüksekliği + 10px tampon), tarayıcı otomatik kaydırma yaptığında
     odaklanmış öğelerin sabit üstbilginin altında kalmadan görünür olmasını sağlar. -->

Çerez Bandının Alttaki Odaklanmış Form Alanını Kapatması — Hatalı

<!-- Üstündeki form alanları için herhangi bir düzenleme olmadan altta sabitlenmiş çerez bandı -->
<div id='cookie-banner' class='cookie-overlay'>
  <p>We use cookies. <button>Accept</button></p>
</div>

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <!-- Bu onay kutusu, çerez bandının kapladığı görünüm alanı bölgesinde render edilir -->
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

Çerez Bandının Alttaki Odaklanmış Form Alanını Kapatması — Doğru

<!-- Çerez bandı, içeriğin üzerine binmek yerine sayfa içeriğini yukarı iter -->
<div id='cookie-banner' class='cookie-banner-flow'>
  <p>We use cookies. <button id='accept-cookies'>Accept</button></p>
</div>

<!-- Stil sayfanızda: -->
<!-- .cookie-banner-flow { position: static; } position: fixed yerine -->
<!-- Alternatif olarak, tasarım nedenleriyle sabit konumlandırma gerekiyorsa,
     tüm odaklanabilir öğelere bant yüksekliğine eşit scroll-margin-bottom ekleyin
     veya <body> öğesine bant yüksekliğine eşit padding-bottom uygulayın ki
     içerik asla bandın altında gizlenmesin. -->

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

Üçüncü Taraf Sohbet Bileşeninin Odaklanmış Düğmenin Üzerine Binmesi — Hatalı

<!-- Sağ alt köşeye enjekte edilen, yüksek z-index’li üçüncü taraf sohbet bileşeni,
     odaklanmış Submit düğmesini gizliyor -->
<div id='chat-widget' class='chat-fixed'>
  <!-- Üçüncü taraf betik tarafından enjekte edilir, sağ altta 120x120px alanı kaplar -->
</div>

<section class='cta-section'>
  <!-- Düğme, düzenin sağ alt bölgesine yerleştirilmiştir;
       odaklandığında sohbet bileşeninin altında tamamen gizlenir -->
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

Üçüncü Taraf Sohbet Bileşeninin Odaklanmış Düğmenin Üzerine Binmesi — Doğru

<!-- Yaklaşım 1: Sohbet bileşenini odaklanabilir içeriğin üzerine binmeyecek şekilde yeniden konumlandırın -->
<div id='chat-widget' class='chat-fixed-adjusted'>
  <!-- Bileşen, CTA düğmesinden uzağa, sol alt köşeye taşındı -->
</div>

<!-- Yaklaşım 2: Düğmenin, odaklandığında bileşenden uzak kalmasını
     sağlayacak scroll-margin’a sahip olduğundan emin olun -->
<section class='cta-section'>
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

<!-- Yaklaşım 3: Sohbet bileşeninin sınırlayıcı kutusuna yakın öğelerdeki
     odak olaylarını algılamak ve odaklanmış öğe görünür olsun diye
     bileşeni geçici olarak daraltmak veya taşımak için JavaScript kullanın. -->
<script>
  // Örnek: Yakındaki öğe odaklandığında bileşeni daralt
  document.querySelectorAll('.cta-button').forEach(function(btn) {
    btn.addEventListener('focus', function() {
      var widget = document.getElementById('chat-widget');
      if (widget) widget.setAttribute('aria-hidden', 'false');
      // Bileşeni yeniden konumlandırmak veya küçültmek için ek mantık
    });
  });
</script>

Yaygın Hatalar

• Odaklanabilir öğelere scroll-margin-top veya scroll-margin-bottom eklemeden üstbilgilere ve altbilgilere position: fixed uygulamak. Tarayıcının yerleşik odak kaydırması, sabit üst üste binen öğeleri hesaba katmaz; bu nedenle odaklanmış öğeler görünüm alanının üstüne veya altına kaydırılır ve sabit katmanın arkasında kalır. * { scroll-margin-top: [header-height]px; } gibi genel bir CSS kuralı bunu verimli şekilde çözer.
• Sabit bir üstbilgiyi telafi etmek için body { padding-top: 60px; } ayarlayıp, klavye odağı için eşdeğer scroll-margin-top eklemeyi unutmak. Bu padding, içeriğin başlangıçta gizlenmemesini sağlar; ancak klavye odağı tarayıcı otomatik kaydırmasını tetiklediğinde, kaydırma hedefi yine de üstbilginin arkasına kayabilir. Her iki yaklaşım da birlikte kullanılmalıdır.
• Tanıtım bantlarına veya sohbet bileşenlerine, hangi odaklanabilir öğelerin ayak izleri içinde kaldığını denetlemeden z-index: 9999 vermek. Yüksek z-index, örtünün odaklanmış düğmeler ve bağlantılar dâhil her şeyin üzerinde render edilmesini garanti eder ve bu da 2.4.11 ihlallerinin en yaygın temel nedenidir.
• Çerez bantlarını JavaScript ile kapatıp, bunları düzenten hemen kaldırmamak. Bantın DOM öğesi visibility: hidden veya opacity: 0 ile kalsa, ancak hâlâ yer kaplıyor veya sıfır olmayan bir z-index’e sahipse, bazı tarayıcı render senaryolarında odaklanmış öğeleri görsel olarak gizlemeye devam edebilir.
• Üçüncü taraf bileşenleri (canlı sohbet, erişilebilirlik örtüleri, GDPR yöneticileri) gömüp, bunların klavye odak görünürlüğü üzerindeki etkisini doğrulamamak. Üçüncü taraf betikler, çoğu zaman çok yüksek z-index değerlerine sahip sabit konumlu öğeler enjekte eder. Ekipler, bu entegrasyonları erişilebilirlik QA süreçlerinin bir parçası olarak özellikle test etmelidir.
• Duyarlı (responsive) kırılma noktası değişikliklerinden sonra 2.4.11’i test etmemek. Masaüstünde 60px yüksekliğinde olan yapışkan bir gezinme çubuğu, tablet görünümünde hamburger menü açıldığında 120px’e genişleyebilir; bu da bir anda çok daha büyük bir alanı kaplayarak masaüstünde geçen, ancak kırılma noktalarında yeni ihlaller yaratan durumlar oluşturur.
• scroll-margin-top özelliğini yalnızca bağlantı hedeflerine (<h2>, <section>) uygulayıp, <input>, <button> ve <a> gibi etkileşimli öğelere uygulamamak. Bağlantı kaydırma ofseti genellikle ele alınır; ancak bağlantı olmayan öğelere yapılan klavye odak otomatik kaydırması da aynı şekilde etkilenir ve aynı CSS kuralıyla kapsanmalıdır.
• Odaklanmış bir öğe ekran okuyucu tarafından duyurulduğu için, görsel olarak da görünür olduğunu varsaymak. Ekran okuyucular erişilebilirlik ağacına erişir, görsel render’a değil. Bir öğe sabit bir örtünün arkasında tamamen gizlenmiş olabilir, ancak NVDA veya JAWS tarafından doğru şekilde duyurulabilir. Bunlar iki ayrı sorundur — 2.4.11, özellikle gören klavye kullanıcıları için görsel odak görünürlüğü ile ilgilidir.
• Tek sayfa uygulaması (SPA) rota değişikliklerinden sonra odak gizlenmesini test etmeyi ihmal etmek. React, Vue veya Angular uygulamalarında rota geçişleri, güncellenmiş durumla sabit üstbilgileri yeniden render eder ve gezinme sırasında odak yönetimi, kullanıcı yeni sayfayı görmeden önce odaklanmış öğeyi yeniden monte edilen yapışkan üstbilginin hemen altına yerleştirebilir.
• Yalnızca otomatik test araçlarına güvenmek ve hiçbir otomatik kural sayfayı işaretlemediği için 2.4.11 sorunu olmadığını varsaymak. Axe-core bu ölçüt için otomatik bir kurala sahip olmadığından, temiz bir otomatik rapor sayfanın geçtiği anlamına gelmez. Tüm görünüm alanı boyutları ve sayfa durumları için manuel klavye geçişi zorunludur.

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

WCAG 2.4.11 Odak Gizlenmemiş (Asgari), Türkiye’nin gelişmekte olan yasal erişilebilirlik çerçevesiyle doğrudan ilişkilidir. 21 Haziran 2025 tarihli ve 32933 sayılı Resmî Gazete’de yayımlanan Türkiye Cumhurbaşkanlığı Genelgesi 2025/10, WCAG 2.2 ile uyumlu zorunlu dijital erişilebilirlik gerekliliklerini belirler. Bu genelge, Türkiye’nin dijital kapsayıcılığa yönelik taahhüdünün önemli bir genişlemesini temsil eder ve Türk dijital pazarında faaliyet gösteren çok çeşitli kuruluşlara bağlayıcı yükümlülükler getirir.

Genelge; 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’den fazla abonesi olan telekomünikasyon şirketleri, seyahat acenteleri, özel ulaşım şirketleri ve Millî Eğitim Bakanlığı (MoNE) tarafından yetkilendirilmiş özel okullar dâhil geniş bir kuruluş yelpazesini kapsar. Bu kuruluşların tümünün, dijital arayüzlerinin — web siteleri, mobil uygulamalar ve web tabanlı araçlar — WCAG 2.2 Seviye AA’ya uygun olmasını sağlaması beklenmektedir.

WCAG 2.4.11, WCAG 2.2’de Seviye AA ölçütü olduğundan, bu kurala uyum kapsamdaki kuruluşlar için isteğe bağlı değildir. Aile ve Sosyal Hizmetler Bakanlığı tarafından verilen resmi Erişilebilirlik Logosu’nu almak veya korumak isteyen kuruluşların Seviye AA uyumunu sağlaması gerekir. Erişilebilirlik Logosu, dijital kapsayıcılık taahhüdünün kamuya açık bir göstergesi olarak hizmet eder ve Türk tüketicileri ile kamu alım mercileri tarafından giderek daha fazla beklenmektedir.

Pratikte bu, yapışkan gezinme üstbilgilerine sahip Türk kamu kurumu web sitelerinin, kalıcı tanıtım bantları olan e-ticaret sitelerinin, kayan yardım bileşenleri bulunan bankacılık portallarının ve çerez onay örtüleri olan sağlık randevu sistemlerinin, 2.4.11 kapsamında odak gizlenmesi açısından test edilmesi ve düzeltilmesi gerektiği anlamına gelir. Bu ölçütteki ihlaller, özellikle karmaşık, pazarlama ağırlıklı arayüzlerde olasıdır — tam da genelge kapsamındaki büyük ticari kuruluşların işlettiği site türleri.

Genelge kapsamındaki kuruluşlar, 2.4.11 testini düzenli erişilebilirlik denetim döngülerine dâhil etmelidir. Bu ölçütün manuel test gerektirdiği göz önüne alındığında, yalnızca otomatik taramaya güvenmek, gerekli özen yükümlülüklerini yerine getirmek için yeterli olmayacaktır. Tam uyum hedefleyen Türk kuruluşlarının, uyum dokümantasyonlarının bir parçası olarak tüm görünüm alanı boyutları ve dinamik sayfa durumları için manuel klavye geçiş testleri yapmaları ve erişilebilirlik logosu başvurusu veya yenilemesinden önce tespit edilen odak gizlenmesi sorunlarını iyileştirme yol haritalarının bir parçası olarak ele almaları tavsiye edilir.