Siteyi Yalnız Klavyeyle Kullanmayı Deneyin: Tab Sırası ve Odak Testi

Fareyi masaya bırakın; sitenizi yalnızca Tab, Shift+Tab, Enter, Boşluk ve Esc tuşlarıyla gezmeyi deneyin. Menüde ikinci öğeye geçerken ekranda hiçbir iz görünmüyorsa ya da açılan bir pencereden çıkış tuşu bulamıyorsanız, otomatik bir tarama aracının hiç yakalamadığı bir engelle karşı karşıyasınız demektir.

Aradaki fark şu: otomatik araçlar sayfanın HTML yapısını denetler, gerçek klavye testi ise odağın gerçekte nereye gittiğini ve orada ne olduğunu gösterir. Aşağıdaki sıra, W3C'nin resmî klavye ve odak ölçütlerine dayanarak nereye bakmanız gerektiğini anlatıyor.

---

Fareyle çalışan bir arayüz klavyeyle neden kilitlenir?​

Bir buton fareyle tıklandığında çalışıyor diye klavyeyle de çalışacağı garanti değildir. Tıklama olayı yalnızca onclick ile bağlanmış, klavye odağı hiç alamayan bir div veya span üzerine kuruluysa, Tab tuşu o öğeye hiç uğramaz. W3C'nin WCAG 2.2 standardı, 2.1.1 Klavye ölçütünde (Seviye A) içeriğin tüm işlevinin, belirli bir tuş zamanlamasına ihtiyaç duymadan yalnızca klavye arayüzüyle çalıştırılabilir olmasını şart koşuyor. Bu ölçüt karşılanmadığında sorun kozmetik değil; o özellik bazı ziyaretçiler için sitede hiç yoktur.

Test sırası: ana sayfadan çıkışa kadar​

Rastgele tıklamak yerine gerçek bir ziyaretçi rotasını izleyin:

1. Ana sayfaya girin, sayfa yüklenir yüklenmez Tab'a basın.
2. Üst menüde tüm öğelere ve alt menülere klavyeyle ulaşın.
3. Arama kutusuna odaklanın, yazın ve sonuç listesine geçin.
4. Bir formu yalnız Tab ve Boşluk/Enter ile doldurup gönderin.
5. Bir modal veya çerez bildirimi açın, içinde gezinin.
6. Modaldan veya bildirimden Esc ya da Tab ile çıkın.

Her adımda tek soru sorun: fare hiç elinizde olmasa bu işi bitirebilir miydiniz?

Odak görünür mü, sırası mantıklı mı?​

Odağın nerede olduğunu göremiyorsanız, doğru öğeye geldiğinizi de bilemezsiniz. W3C WAI'nin Easy Checks rehberindeki görünür odak testi, Tab ile gezinirken her etkileşimli öğenin belirgin bir görsel stille işaretlenmesi gerektiğini ve bunun yalnızca hareket bozukluğu olan kullanıcılar için değil, klavye ile gezinen görme engelli kullanıcılar için de önemli olduğunu anlatıyor. WCAG 2.2'de bu gereksinim 2.4.7 Odak Görünür ölçütüyle (Seviye AA) karşılanıyor; 2.4.11 Odak Gizlenmemeli (Asgari) ölçütü de (Seviye AA) odaklanan öğenin, sayfadaki başka bir içerikle tamamen kapatılmamasını istiyor.

Görünürlük tek başına yetmez, sıra da mantıklı olmalı. 2.4.3 Odak Sırası ölçütü (Seviye A), sıralı gezinmenin anlamı etkilediği sayfalarda odağın, anlamı ve kullanılabilirliği koruyan bir sırayla ilerlemesini şart koşuyor. Görsel olarak sağ üstte duran arama kutusuna klavyeyle ancak sayfanın ortasından sonra ulaşılıyorsa, bu ölçüt karşılanmıyor demektir.

Klavye tuzağı: modal Tab ile dönüyor mu, Esc kapatıyor mu?​

Bir modal açıldığında odak içeride kalmalı ama asla kilitlenmemeli. WCAG 2.2 standardının klavye tuzağı maddesi, klavyeyle bir bileşene odaklanılabiliyorsa oradan yalnızca klavyeyle de çıkılabilmesi gerektiğini (2.1.2 Klavye Tuzağı Yok, Seviye A) söylüyor. WAI-ARIA Authoring Practices'in modal iletişim kutusu deseni, son tabbable öğeden sonra Tab'ın diyalog içindeki ilk öğeye, ilk öğeden önce basılan Shift+Tab'ın ise son öğeye dönmesini; Esc tuşunun diyalogu kapatmasını tarif ediyor. Kapanınca odağın, diyalogu açan öğeye geri dönmesi öneriliyor.

Basit ayrım' Alıntı:

Fare için sorunsuz çalışan bir modal, klavye için kilit olabilir; ikisini aynı testte saymayın.

Genişletmek için tıkla ...

Sık çıkan üç hata ve düzeltme yönü​

• tabindex kötüye kullanımı: Pozitif değerler (tabindex="1", "2" gibi) sayfanın doğal DOM sırasını bozup odağı beklenmedik yere sıçratır. Sıra sorunuysa genelde çözüm, öğeleri HTML'de doğru sıraya taşımaktır.
• div ile buton taklidi: Üstüne tıklama olayı eklenmiş ama gerçek bir button veya a href olmayan öğe, Tab ile hiç seçilemez veya seçilse bile Enter/Boşluk ile tetiklenmez.
• outline:none: Odak çerçevesini kaldıran bir CSS kuralı, yerine görünür başka bir stil konmadan bırakılırsa 2.4.7 Odak Görünür ölçütünü doğrudan ihlal eder.

Bulguyu nasıl kaydedersiniz?​

Bir sorunu "menü bozuk" diye not almak yerine dört bilgiyi birlikte yazın: hangi sayfa, hangi tuş dizisi, beklenen davranış, gerçekte gözlenen davranış. Örneğin "ana sayfa → üst menü ikinci öğe → Enter; beklenen: alt menü açılır; gözlenen: hiçbir şey olmuyor" satırı, geliştiricinin sorunu yeniden üretmesini kolaylaştırır. Ekran görüntüsü yerine bu dört alanı dolduran kısa bir kayıt, uzun vadede daha az soru-cevap gerektirir.

Bu testi sitenin genel erişilebilirlik hedefleriyle birlikte düşünmek isterseniz erişilebilirlik ve kapsayıcı tasarım yazısına, renk tarafını ayrıca ölçmek isterseniz WCAG 2.2 ile kontrast ölçümü rehberine bakabilirsiniz. Kurumsal bir sitede bu testleri hangi aşamada yapmanız gerektiğini merak ediyorsanız kurumsal web tasarımı yazısı süreci baştan anlatıyor.

Özetle​

Klavye testi kısa bir alışkanlıktır: menüden forma, modaldan çıkışa kadar Tab, Shift+Tab, Enter, Boşluk ve Esc ile ilerleyin; odağın göründüğünü, mantıklı sırayla aktığını ve hiçbir yerde kilitlenmediğinizi doğrulayın. Otomatik tarayıcı araçları bu deneyimin yerini tutmaz, yalnızca başlangıç noktası verir. Kendi sitenizde klavyeyle takıldığınız ilk yer neresi oldu?

Güncelleme: 21 Ağustos 2026. W3C WCAG 2.2, WAI Easy Checks ve WAI-ARIA Authoring Practices güncel resmî sayfaları kontrol edildi.

---