WCAG Başarı Kriterleri · Level A

WCAG 2.1.2: Klavye Tuzağı Yok

WCAG 2.1.2, klavye kullanıcılarının hiçbir zaman bir bileşenin içinde sıkışıp kalmamasını gerektirir — odak klavye kullanılarak bir arayüz öğesinin içine taşınabiliyorsa, yalnızca klavye kullanarak odağı o öğeden uzaklaştırmak da mümkün olmalıdır. Bu ölçüt, motor engelli kişiler ve ekran okuyucu kullanıcıları dahil olmak üzere, yalnızca klavye ile gezinmeye güvenen kullanıcılar için hayati önem taşır.

Bu Kuralın Anlamı

WCAG 2.1.2 — Klavye Tuzağı Yok — İşletilebilirlik ilkesinin altında Seviye A başarı ölçütüdür. Şöyle der: "Klavye odağı bir sayfa bileşenine klavye arayüzü kullanılarak taşınabiliyorsa, odak yalnızca klavye arayüzü kullanılarak o bileşenden uzaklaştırılabilmeli ve odak uzaklaştırmak için değiştirilmemiş yön tuşları veya sekme tuşları dışında bir şey gerekiyorsa, kullanıcıya odağı uzaklaştırma yöntemi bildirilmelidir."

Pratikte bu, bir klavye kullanıcısının sekme ile içine girebildiği her etkileşimli bileşenin, kullanıcının sekme ile dışına çıkmasına da izin vermesi gerektiği anlamına gelir. Bir kullanıcı bir bileşenin, iletişim kutusunun, özel form kontrolünün, gömülü medya oynatıcısının veya başka herhangi bir odaklanabilir bölgenin içine klavye ile girip standart klavye kontrolleriyle oradan çıkamadığında — fiilen sıkışıp kaldığında — klavye tuzağı oluşur.

Bu ölçüt, klavye odağı alabilen tüm HTML öğelerini kapsar: <input>, <select>, <textarea>, <button> ve <a> etiketleri gibi yerel etkileşimli öğeler ile tabindex, ARIA rolleri veya JavaScript odak yönetimi aracılığıyla odak alan özel bileşenler. Sohbet bileşenleri, video oynatıcılar, harita gömüleri, tarih seçiciler ve zengin metin editörleri gibi gömülü üçüncü taraf bileşenler için de aynı şekilde geçerlidir.

Bir bileşen, bir klavye kullanıcısı her zaman standart tuşları — genellikle Tab, Shift+Tab, Escape veya yön tuşları — kullanarak odağı ondan uzaklaştırabiliyorsa ya da sayfa, odağı uzaklaştırmak için standart olmayan bir klavye mekanizmasını kullanıcıya açıkça bildiriyorsa, bu ölçütü geçer. Odağın, klavye ile erişilebilir hiçbir çıkış yolu olmadan bileşenin içinde kilitli kalması ya da tek çıkış mekanizmasının fare tıklaması, dokunma hareketi veya başka bir klavye dışı girdi gerektirmesi durumunda bileşen kalır.

WCAG dar bir istisna sağlar: klavye odağını bir bileşenin içinde geçici olarak sınırlamak, bu durum kasıtlı ve erişilebilir bir tasarım deseninin parçası olduğunda kabul edilebilir — en belirgin örnek, modal iletişim kutusudur. Bir modal iletişim kutusu, açık olduğu sürece odağı iletişim kutusunun içinde tutmalıdır (kullanıcıların arkadaki gizlenmiş içerikle etkileşime girmesini önlemek için), ancak her zaman iletişim kutusunu kapatmak ve odağı serbest bırakmak için klavye ile erişilebilir bir yol sağlamalıdır — örneğin Escape tuşu işleyicisi veya Tab ile erişilebilen, açıkça etiketlenmiş bir kapatma düğmesi gibi. Bu tür kasıtlı, kaçılabilir odak sınırlaması bir klavye tuzağı değildir; modal iletişim kutusu deseninin doğru bir uygulamasıdır. Tuzak, ancak kullanıcı hiç kaçamadığında bir başarısızlık haline gelir.

Neden Önemlidir

Klavye tuzakları, bir web sitesinin sahip olabileceği en ciddi erişilebilirlik hatalarından biridir. Bazı kullanıcılar için deneyimi kötüleştiren diğer birçok erişilebilirlik sorunundan farklı olarak, bir klavye tuzağı, bir kullanıcının bir sayfayı kullanmaya devam etmesini tamamen engelleyebilir. Bu, bir koridora fiziksel bir bariyer koyup etrafından dolaşmak için hiçbir yol bırakmamaya eşdeğerdir.

En ağır etkilenen gruplar, fare kullanamayan ve tamamen klavye ile gezinmeye güvenen motor veya fiziksel engelli kullanıcılardır. Buna tekrarlayan zorlanma yaralanması, multipl skleroz, Parkinson hastalığı, kuadripleji ve serebral palsi gibi durumları olan kişiler dahildir. Dünya Sağlık Örgütü’ne göre, yaklaşık 1,3 milyar insan — küresel nüfusun %16’sı — önemli bir engellilik biçimiyle yaşamaktadır ve motor bozukluklar bu rakamın önemli bir bölümünü temsil eder. Bu kullanıcılar için, bir ödeme sayfasında, giriş formunda veya müşteri hizmetleri sohbet bileşeninde klavye tuzağıyla karşılaşmak, görevi tamamen tamamlayamamak anlamına gelebilir.

Ekran okuyucu kullanıcıları — ağırlıklı olarak kör ve az gören kullanıcılar — da ciddi şekilde etkilenir. NVDA, JAWS ve VoiceOver gibi ekran okuyucular tamamen klavye komutlarıyla gezinir. Odağın bir bileşende sıkışması durumunda, ekran okuyucu kullanıcısı Tab tuşuna bastıkça aynı öğeyi tekrar tekrar duyar ve sayfada ileri veya geri gitmenin hiçbir yolu yoktur. Bu son derece kafa karıştırıcıdır ve kullanıcıyı, yaptığı tüm ilerlemeyi kaybederek tarayıcı sekmesini kapatmaya veya sayfayı yenilemeye zorlar.

Şu gerçek dünya senaryosunu düşünün: Sınırlı el hareketliliğine sahip bir kullanıcı, bir ürün satın almak için bir Türk e-ticaret sitesini ziyaret eder. Sepetine bir ürün ekler ve ödemeye geçer. Ödeme sayfasında, özel bir JavaScript framework’ü ile oluşturulmuş üçüncü taraf bir adres otomatik tamamlama bileşeni bulunur. Adres alanı odağı aldığında bileşen bir açılır öneri listesi açar. Geliştirici, bu açılır listeyi kapatmak için klavye olay işleme eklemeyi unutmuştur — bu nedenle kullanıcı adres alanına sekme ile girip açılır liste göründüğünde, sekme ile dışarı çıkamaz, Escape’e basamaz ve fare tıklaması olmadan açılır listeyi kapatamaz. Kullanıcı, satın alma işlemini tamamlamaktan tamamen alıkonur. Bu küçük bir rahatsızlık değil — hizmetten tam bir dışlanmadır.

Engellilik erişiminin ötesinde, klavye tuzakları, hız için klavye ile gezinmeyi tercih eden ileri düzey kullanıcıları, fare kullanımının kısıtlandığı kurumsal ortamlardaki kullanıcıları ve donanım klavyeli bazı mobil veya hibrit cihaz kullanıcılarını da etkiler. Bu nedenle klavye tuzaklarını düzeltmek, yalnızca engelli kullanıcılar için değil, daha geniş bir kullanıcı kitlesi için de deneyimi iyileştirir.

İlgili Axe-core Kuralları

WCAG 2.1.2 manuel test gerektirir. Hiçbir otomatik axe-core kuralı klavye tuzaklarını doğrudan ve güvenilir şekilde tespit etmez. Bunun nedeni, otomatik araçların DOM’un statik yapısını analiz ederek çalışmasıdır — odaklanabilir öğeleri belirleyebilir, sekme sırasını kontrol edebilir ve ARIA özniteliklerini doğrulayabilirler, ancak bir insan testçinin gerçekleştirdiği tam etkileşimli klavye gezinme deneyimini simüle edemezler. Klavye tuzağı genellikle, çalışma zamanında klavye olaylarını yakalayan veya bastıran JavaScript olay işleme mantığından kaynaklanır; bu davranış DOM yapısında görünmez ve statik bir analiz aracı tarafından çıkarılamaz.

  • Manuel test gerekli — özel bir axe-core kuralı yoktur: Axe-core, klavye tuzaklarını otomatik olarak tespit eden bir kural sunmaz çünkü başarısızlık modu temelde davranışsaldır. Tuzak yalnızca bir kullanıcı Tab tuşuyla gerçekten bir bileşenin içine girip çıkmaya çalıştığında ortaya çıkar. Bir otomatik tarayıcı bunu çoğaltamaz; çünkü sayfadaki her odaklanabilir öğe üzerinde sıralı klavye gezinmesini simüle etmesi, ilişkili tüm JavaScript olay dinleyicilerini tetiklemesi ve ardından odağın amaçlanan bölgeden kaçıp kaçmadığını belirlemesi gerekir — bu, karmaşık sayfalar için hesaplama açısından çözülemez bir problemdir. Ayrıca, neyin tuzak neyin kasıtlı odak sınırlaması (örneğin bir modal) olduğuna karar vermek, otomatik kuralların güvenilir şekilde yapamayacağı bağlamsal bir yargı gerektirir. Testçiler, odaklanabilir öğeleri ve sekme sırası sorunlarını başlangıç noktası olarak belirlemek için axe DevTools veya Lighthouse kullanmalı, ancak ardından her etkileşimli bölgeyi manuel olarak klavye ile gezerek tuzak olmadığını doğrulamalıdır.

Nasıl Test Edilir

  1. Temel olarak otomatik bir erişilebilirlik taraması çalıştırın. Axe DevTools (tarayıcı eklentisi) açın veya Chrome DevTools’ta bir Lighthouse erişilebilirlik denetimi çalıştırın. Bu araçların hiçbiri doğrudan bir klavye tuzağını işaretlemese de, tarama odaklanabilir öğeleri, eksik ARIA rolleri ve riskli etkileşimli bileşenlere işaret edebilecek hatalı sekme sırasını belirleyecektir. Herhangi bir özel bileşeni, gömülü iframe’leri, üçüncü taraf bileşenleri, modal iletişim kutularını, açılır menüleri, tarih seçicileri, karuselleri ve zengin metin editörlerini not edin — bunlar klavye tuzaklarının en yaygın kaynaklarıdır.
  2. Farenizi çıkarın veya bir kenara koyun. Manuel klavye testinin geçerli olması için fare kullanmamalısınız. Test sırasında yanlışlıkla fareye güvenmemek için farenizi ulaşamayacağınız bir yere koyun veya işletim sistemi ayarlarından devre dışı bırakın.
  3. Tüm sayfada yalnızca Tab ve Shift+Tab tuşlarını kullanarak gezinin. Tarayıcı adres çubuğundan veya sayfanın üstünden başlayarak, Tab tuşuna art arda basın ve odağın nereye taşındığını gözlemleyin. Her adımda odak göstergesini görsel olarak takip edin. Her etkileşimli bileşene — özellikle özel bileşenlere, gömülü içeriklere veya karmaşık arayüz öğelerine — ulaştığınızda, Tab veya Shift+Tab tuşuna basmanın odağı bileşenden temiz bir şekilde sayfadaki bir sonraki veya önceki odaklanabilir öğeye taşıdığını doğrulayın.
  4. Her etkileşimli bileşeni tek tek test edin. Modal iletişim kutuları için: modali açın, odağın içine taşındığını doğrulayın, ardından Escape’e basın ve odağın tetikleyici öğeye geri döndüğünü doğrulayın. Açılır menüler için: açılır menüyü açın, içinde gezin, ardından Escape’e basın ve açılır menünün kapandığını ve odağın tetikleyiciye döndüğünü doğrulayın. Tarih seçiciler, renk seçiciler ve benzeri bileşenler için: sekme ile içeri girin, etkileşime geçin, ardından sekme ile dışarı çıkın ve odağın çıktığını doğrulayın. Gömülü iframe’ler (örneğin haritalar, video oynatıcılar, sohbet bileşenleri) için: iframe’in içine sekme ile girin, içinde gezin ve sekme ile ana sayfaya geri çıkabildiğinizi doğrulayın.
  5. NVDA ve Firefox ile test edin. NVDA’yı açın, sayfaya Firefox’ta gidin ve etkileşimli öğeler arasında gezinmek için Tab kullanın. NVDA’nın her Tab basışında yeni bir öğe okuyup okumadığına veya aynı öğeye geri dönüyor gibi görünüp görünmediğine dikkat edin. Tab, odağı bir bileşenin ötesine taşıyamıyorsa bu bir klavye tuzağıdır.
  6. macOS’ta VoiceOver ve Safari ile test edin. VoiceOver’ı etkinleştirin (Command + F5), sayfayı Safari’de açın ve gezinmek için Tab tuşunu kullanın. VoiceOver’ın her Tab basışında yeni bir öğe duyurduğunu ve odağın çıkamadığınız bir bölgede asla sıkışmadığını doğrulayın.
  7. JAWS ve Chrome ile test edin. JAWS’ı açın, sayfaya Chrome’da gidin ve tüm etkileşimli bileşenler arasında gezinmek için Tab kullanın. Özellikle JavaScript ile yönetilen odak kullanan bileşenleri test edin; çünkü JAWS, yalnızca görsel testle görünmeyen tuzakları ortaya çıkarabilecek şekilde erişilebilirlik ağacıyla etkileşime girer.
  8. Standart olmayan kaçış mekanizmalarını kontrol edin. Herhangi bir bileşenden çıkmak için Tab, Shift+Tab veya Escape dışında bir tuş gerekiyorsa, sayfanın bunu kullanıcıya açıkça ilettiğini doğrulayın — örneğin ekrandaki talimatlar, bir araç ipucu veya odağın bileşene girdiği anda tetiklenen bir ARIA canlı bölge duyurusu aracılığıyla.

Nasıl Düzeltilir

Escape İşleme Olmayan Modal İletişim Kutusu — Hatalı

<!-- Modal açılıyor ancak Escape tuşu işleyicisi yok ve klavye ile erişilebilen kapatma düğmesi yok -->
<div id='modal' role='dialog' aria-modal='true' aria-labelledby='modal-title'>
  <h2 id='modal-title'>Confirm Your Order</h2>
  <p>Are you sure you want to place this order?</p>
  <button onclick='submitOrder()'>Confirm</button>
  <!-- Kapatma düğmesi yok, Escape tuşu dinleyicisi yok -- klavye kullanıcıları tuzağa düşüyor -->
</div>

Escape İşleme Olmayan Modal İletişim Kutusu — Doğru

<!-- Doğru odak tuzağı, Escape işleyicisi ve erişilebilir kapatma düğmesi olan modal -->
<div id='modal' role='dialog' aria-modal='true' aria-labelledby='modal-title'>
  <h2 id='modal-title'>Confirm Your Order</h2>
  <p>Are you sure you want to place this order?</p>
  <button onclick='submitOrder()'>Confirm</button>
  <!-- Kapatma düğmesi Tab ile erişilebilir ve klavye kullanıcılarının çıkmasına izin verir -->
  <button id='modal-close' onclick='closeModal()' aria-label='Close dialog'>Cancel</button>
</div>

<script>
  document.addEventListener('keydown', function(e) {
    if (e.key === 'Escape') {
      closeModal(); // Escape tuşu modali kapatır ve odağı tetikleyiciye geri döndürür
    }
  });

  function closeModal() {
    document.getElementById('modal').hidden = true;
    document.getElementById('modal-trigger').focus(); // Odağı açana geri döndür
  }
</script>

Tüm Tab Tuşu Olaylarını Yakalayan Özel Açılır Liste — Hatalı

<!-- Özel açılır liste, Tab dahil tüm keydown olaylarını yakalar ve odağın çıkmasını engeller -->
<div id='custom-select' tabindex='0' role='combobox' aria-expanded='true'>
  <ul role='listbox'>
    <li role='option' tabindex='-1'>Option 1</li>
    <li role='option' tabindex='-1'>Option 2</li>
    <li role='option' tabindex='-1'>Option 3</li>
  </ul>
</div>

<script>
  // HATA: Bu, TÜM klavye olaylarını yakalar ve Tab üzerinde preventDefault çağırır,
  // yani kullanıcı bu bileşenden asla Tab ile çıkamaz
  document.getElementById('custom-select').addEventListener('keydown', function(e) {
    e.preventDefault(); // Bu klavyeyi tuzağa düşürür
    if (e.key === 'ArrowDown') { /* odağı aşağı taşı */ }
    if (e.key === 'ArrowUp') { /* odağı yukarı taşı */ }
  });
</script>

Tüm Tab Tuşu Olaylarını Yakalayan Özel Açılır Liste — Doğru

<!-- Doğru: Yalnızca dahili gezinme için kullanılan yön tuşları için varsayılanı engelle;
     kullanıcıların çıkabilmesi için Tab ve Escape’in normal çalışmasına izin ver -->
<div id='custom-select' tabindex='0' role='combobox' aria-expanded='false'>
  <ul role='listbox' hidden>
    <li role='option' tabindex='-1'>Option 1</li>
    <li role='option' tabindex='-1'>Option 2</li>
    <li role='option' tabindex='-1'>Option 3</li>
  </ul>
</div>

<script>
  document.getElementById('custom-select').addEventListener('keydown', function(e) {
    if (e.key === 'ArrowDown' || e.key === 'ArrowUp') {
      e.preventDefault(); // Yalnızca dahili gezinme tuşları için varsayılanı engelle
      // seçenekler arasında odağı taşı
    }
    if (e.key === 'Escape' || e.key === 'Tab') {
      // preventDefault ÇAĞIRMAYIN -- Tab ve Escape’in yayılmasına izin verin
      // böylece tarayıcı odağı bu bileşenden doğal olarak uzaklaştırabilsin
      closeDropdown();
    }
  });
</script>

Çıkış Yolu Olmayan Gömülü Üçüncü Taraf Iframe — Hatalı

<!-- Tüm Tab tuşu basışlarını emen ve odağı asla üst sayfaya geri döndürmeyen
     gömülü sohbet bileşeni iframe’i -->
<iframe
  src='https://example-chat-widget.com/embed'
  title='Customer support chat'
  width='350'
  height='500'>
</iframe>
<!-- Iframe’in içindeki JavaScript, Tab olaylarını tüketir ve kullanıcıları içinde tuzağa düşürür -->

Çıkış Yolu Olmayan Gömülü Üçüncü Taraf Iframe — Doğru

<!-- Klavye kullanıcılarını tuzağa düşürebilecek bir iframe gömmek yerine
     sohbeti yeni bir pencerede açmak için bir düğme kullanın -->
<button
  id='open-chat'
  onclick='window.open("https://example-chat-widget.com", "_blank", "noopener")'>
  Open Customer Support Chat (opens in new window)
</button>

<!-- Bir iframe kullanmak zorundaysanız, öncesine görünür bir atla bağlantısı ekleyin
     böylece klavye kullanıcıları isterlerse bunu atlayabilsin -->
<a href='#after-chat-widget' class='skip-link'>Skip chat widget</a>
<iframe
  src='https://example-chat-widget.com/embed'
  title='Customer support chat'
  width='350'
  height='500'>
</iframe>
<span id='after-chat-widget' tabindex='-1'></span>

Yaygın Hatalar

  • keydown dinleyicisi içinde, belirli tuşlara sınırlamadan event.preventDefault() çağırmak — odaklanabilir bir bileşen üzerindeki tüm klavye olaylarına preventDefault() uygulamak, Tab ve Shift+Tab’in çalışmasını engeller ve anında bir klavye tuzağı oluşturur. preventDefault()’u her zaman yalnızca bileşeninizin dahili olarak işlemesi gereken belirli tuşlara (örneğin listbox’lar için yön tuşları) sınırlayın.
  • Odağı içine ayarlayan ancak Escape tuşu işleyicisi veya kapatma düğmesi olmayan bir modal iletişim kutusu oluşturmak — geliştiriciler sıklıkla modal deseninin odak giriş kısmını doğru uygular, ancak odak sınırlamasının yalnızca her zaman klavye ile erişilebilir bir çıkış varsa kabul edilebilir olduğunu unutur. Her modal, Escape tuşunu işleyecek ve sekme ile erişilebilir bir kapatma düğmesi içerecek şekilde tasarlanmalıdır.
  • Bir kapsayıcı öğede, sekme sırasına girmesini önlemek için tabindex='-1' kullanmak, ancak JavaScript’in odağı programatik olarak içine taşımasına izin vermek — odak, element.focus() aracılığıyla tabindex='-1' olan bir öğeye taşındığında, oradan çıkmak için doğal bir Tab hedefi yoktur; ek klavye işleme uygulanmadıysa bu, kullanıcıyı ortada bırakabilir.
  • Üçüncü taraf bileşenleri (sohbet, haritalar, video) klavye tuzağı davranışı açısından denetlemeden gömmek — sağlayıcılar gömülü bileşenlerini her zaman klavye ile erişilebilir şekilde oluşturmaz. Site sahipleri, üçüncü taraf gömüler dahil sayfalarındaki tüm içerikten sorumlu olmaya devam eder. Gömülü bileşenleri her zaman manuel olarak test edin ve klavye kullanıcılarını tuzağa düşürüyorlarsa, bunları bir atla bağlantısıyla sarmalayın veya klavye açısından güvenli bir alternatifle değiştirin.
  • Bir modal veya çekmece için odak tuzağı uygulayıp bileşen kapandığında tuzağı serbest bırakmamak — odağı sınırlayan JavaScript, modal kapandığında düzgün şekilde temizlenmezse, Tab olaylarını yakalamaya ve kullanıcıyı artık görünmeyen katmanda tuzağa düşürmeye devam edebilir.
  • Görsel tasarım nedenleriyle bir iletişim kutusunun kapatma düğmesini gizlemek için CSS ile visibility: hidden veya display: none kullanmak, ancak alternatif bir klavye çıkışı sağlamamak — kapatma düğmesi görsel olarak gizlenmiş ancak erişilebilirlik ağacından kaldırılmamışsa, ekran okuyucu kullanıcıları onu yine de bulabilir; ancak erişilebilirlik ağacından da gizlenmişse, çıkış olmayabilir. Tüm kapatma mekanizmalarının, görsel olarak sadeleştirilmiş şekilde stillendirilmiş olsalar bile klavye ile çalıştığını doğrulayın.
  • Öneri listesi açan ve ardından tüm Tab tuşu basışlarını, çıkmak yerine öneriler arasında dolaşmaya yönlendiren özel otomatik tamamlama veya yazdıkça öneren bileşenler oluşturmak — kullanıcılar, öneri listesini kapatmak için Escape’e ve bir sonraki form alanına geçmek için Tab’e basabilmelidir. Tab’i dahili gezinmeye yönlendiren otomatik tamamlama bileşenleri bu ölçütü ihlal eder.
  • Zengin metin editörlerini (TinyMCE, CKEditor veya Quill gibi WYSIWYG editörler) test etmeyi unutmak — bu bileşenler kendi klavye etkileşimlerini dahili olarak yönetir ve sık görülen klavye tuzağı kaynaklarıdır. Escape’e veya belgelenmiş bir tuş dizisine basmanın editörden çıkıp odağı sayfanın normal sekme sırasına geri döndürdüğünü her zaman doğrulayın.
  • Bir bileşen yerel HTML öğeleri kullandığı için klavye tuzağı olamayacağını varsaymak — blur olayını JavaScript ile geçersiz kılan bir form içindeki <select> öğesi bile odağı tuzağa düşürebilir. Anlamlı HTML kullanımı, üzerine özel JavaScript olay işleme eklendiğinde klavye tuzağı olmayan davranışı garanti etmez.
  • Bir bileşenden çıkmak için standart olmayan bir tuş gerektiğinde ekranda dokümantasyon sağlamamak — WCAG 2.1.2, kullanıcı bilgilendirildiği sürece, bileşenlerin çıkmak için standart olmayan tuşlar gerektirmesine açıkça izin verir. Bileşeninizden çıkmak için F6’ya veya özel bir tuş kombinasyonuna basmak gerekiyorsa, bunu kullanıcıya açıkça iletmelisiniz; ideal olarak bileşenin yanında görünür talimatlar veya odağın bileşene girdiği anda tetiklenen bir ARIA canlı bölge duyurusu aracılığıyla.

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 çok çeşitli kamu ve özel sektör kuruluşu için bağlayıcı dijital erişilebilirlik gereklilikleri getirir. Genelge, uluslararası kabul görmüş web erişilebilirlik standartlarına uyumu zorunlu kılar — temel seviye olarak WCAG 2.1 Seviye AA ile uyumlanır; bu da WCAG 2.1.2 Klavye Tuzağı Yok dahil tüm Seviye A ölçütlerini kapsar.

WCAG 2.1.2, asgari uyum seviyesini temsil eden bir Seviye A ölçütüdür. Genelge kapsamında, Seviye A uyumu tüm kapsanan kuruluşlar için zorunludur. Kamu kurumlarının, genelgenin yayımlanmasından itibaren bir yıl içinde bu uyumu sağlaması gerekirken, özel sektör kuruluşlarına uyum için iki yıl süre tanınmıştır.

Genelge kapsamındaki kuruluşlar geniştir ve tüm düzeylerdeki kamu kurumları ve devlet organlarını, e-ticaret platformlarını ve çevrimiçi pazar yeri işletmecilerini, bankaları ve finansal hizmet kuruluşlarını, hastaneleri ve sağlık hizmeti sağlayıcılarını, 200.000 veya daha fazla abonesi olan telekomünikasyon şirketlerini, seyahat acentelerini, özel ulaşım şirketlerini ve Millî Eğitim Bakanlığı (MoNE) tarafından yetkilendirilmiş özel okulları içerir. Bu, bu kuruluşlardan herhangi biri tarafından işletilen bir web sitesinde veya web uygulamasında klavye tuzaklarının giderilmemesinin, Türkiye’nin zorunlu erişilebilirlik düzenlemelerinin doğrudan ihlali anlamına geldiği anlamına gelir.

Özellikle çevrimiçi bankacılık portalları, hastane randevu alma sistemleri, e-ticaret ödeme akışları ve telekom hesap yönetim sayfaları gibi karmaşık web uygulamalarında klavye tuzağı hatalarının yaygınlığı göz önüne alındığında, WCAG 2.1.2 Türk uyum bağlamında özel dikkat gerektirir. Bunlar, istemeden klavye kullanıcılarını tuzağa düşürebilecek özel bileşenlerin, modal iletişim kutularının ve üçüncü taraf gömülerinin bulunma olasılığının en yüksek olduğu, etkileşim yoğun, JavaScript ile çalışan arayüz türleridir.

Genelgeye tabi kuruluşlar, klavye tuzağı testini erişilebilirlik denetim süreçlerinin vazgeçilmez bir parçası olarak ele almalıdır. Otomatik araçlar klavye tuzaklarını güvenilir şekilde tespit edemediğinden, kapsanan kuruluşların, uyum yolculuklarının bir parçası olarak, tercihen engelli kullanıcıları da içeren nitelikli erişilebilirlik uzmanları tarafından yürütülen manuel klavye testlerine yatırım yapması gerekir. Denetim sırasında tespit edilen klavye tuzaklarını gidermemek, yalnızca genelge kapsamında hukuki bir risk oluşturmakla kalmaz, aynı zamanda dijital hizmetleri kullanmak için klavye ile gezinmeye güvenen motor ve görme engelli kullanıcılar için önemli bir erişim engeli anlamına gelir.