Klavye Dostu Site Menüsü: Odak, Bağlantı Sırası ve Alt Menüler

Bir sitenin menüsünü değerlendirmek için fareyi birkaç dakika kullanmamak yeterince öğretici olabilir. Tab tuşuna bastığınızda hangi bağlantının seçildiği belli mi? Alt menü açılabiliyor mu? Mobil görünümde açılan panel kapatılabiliyor mu? Bu sorular, menünün yalnızca üzerine gelme efektlerinden ibaret olmadığını gösterir.

Klavye dostu gezinme, çok sayıda ARIA özniteliği eklemekle başlamaz. Önce bağlantıların düzenli bir yapıda bulunması, doğal klavye davranışlarının korunması ve görünür odağın takip edilebilmesi gerekir. Aşağıdaki yaklaşım, küçük işletme siteleri ve içerik ağırlıklı bloglar için sade bir başlangıç sunar.

Basit bir gezinme yapısıyla başlayın

Beş bağlantıdan oluşan bir menüyü sırf alışılmış olduğu için açılır panellere bölmeyin. Önce bağlantıların masaüstünde yan yana, dar ekranda ise alt satırlara geçerek gösterilip gösterilemeyeceğini değerlendirin. Daha az gizleme, daha az durum yönetimi ve daha kısa bir kontrol listesi anlamına gelir.

<a href="#ana-icerik">Ana içeriğe geç</a>

<nav class="site-menusu" aria-label="Ana gezinme">
  <ul>
    <li><a href="/">Ana sayfa</a></li>
    <li><a href="/hizmetler">Hizmetler</a></li>
    <li><a href="/yazilar" aria-current="page">Yazılar</a></li>
    <li><a href="/iletisim">İletişim</a></li>
  </ul>
</nav>

<main id="ana-icerik" tabindex="-1">
  ...
</main>

Bu iskelette bağlantılar gerçek sayfa adreslerine gider. aria-current="page" yalnızca ziyaretçinin bulunduğu sayfanın bağlantısına eklenir; bütün bağlantılarda kullanılmaz. Sitenizin başında ve sonunda ayrı gezinme bölgeleri varsa bunları “Ana gezinme” ve “Alt bilgi” gibi anlamlı adlarla ayırt edebilirsiniz.

Başlangıçtaki geçiş bağlantısı, her sayfada aynı menüyü dolaşmadan içeriğe ulaşma yolu sağlar. W3C'nin ana içeriğe geçiş bağlantısı tekniği, bu davranışın nasıl kontrol edileceğini anlatır. Örnekte bağlantı sürekli görünürdür. Tasarımda yalnızca odaklanınca gösterilecekse odak aldığı anda görünmesi ve üst katmanların arkasında kalmaması ayrıca sağlanmalıdır.

Odağı tasarımın parçası yapın

W3C'nin görünür odak açıklamasına göre kullanıcı klavyeyle işlem yaparken hangi öğede olduğunu anlayabilmelidir. Tarayıcının çizdiği dış çizgiyi kaldırıp yerine hiçbir belirti koymamak, gezinmeyi tahmin oyununa dönüştürür.

.site-menusu a:focus-visible,
.site-menusu button:focus-visible {
  outline: 3px solid #173f8a;
  outline-offset: 4px;
}

Bu CSS, menünün kapsayıcısında site-menusu sınıfı bulunduğunu varsayar. Rengi kendi arka planlarınız üzerinde kontrol edin. Beyaz zeminde belirgin bir çizgi, koyu zeminde kaybolabilir. Ayrıca bağlantının çevresindeki kapsayıcı taşmayı kesiyorsa odak çizgisi kırpılabilir. Yalnızca renk değişimi yerine açıkça seçilebilen bir biçim değişikliği tercih etmek değerlendirmeyi kolaylaştırır.

Görsel sırayla klavye sırasını ayırmayın

Menüyü CSS ile yeniden sıralamak, belge içindeki bağlantı sırasını kendiliğinden değiştirmez. Ekranda soldan sağa ilerleyen bağlantılar arasında klavye odağının ileri geri sıçraması bu yüzden görülebilir. Çözümü her öğeye 1, 2, 3 şeklinde tabindex atamakta aramayın.

MDN tabindex belgesi, pozitif değerlerden kaçınmayı ve doğal belge sırasını korumayı önerir. Normal bağlantılar ve düğmeler zaten klavye akışına katılır. Örnekte ana içerikteki tabindex="-1" ise bölgeyi normal Tab sırasına eklemeden programatik odaklanmaya uygun hâle getirir. Bu kullanım, bütün içerik paragraflarını odaklanabilir yapmanız gerektiği anlamına gelmez.

Alt menü gerekiyorsa davranışı açıkça tanımlayın

Bir başlık hem sayfaya götürüyor hem alt menü açıyorsa iki görevi tek, belirsiz tıklama alanına sıkıştırmayın. Sayfa bağlantısıyla açma düğmesini ayırmak daha anlaşılır olabilir. Açma işlemini gerçek bir button üstlensin; düğmenin açık veya kapalı durumu aria-expanded ile gerçek görünürlükle uyumlu tutulsun.

W3C'nin açılır gezinme örneği, sıradan site bağlantılarında neden otomatik olarak role="menu" kullanılmadığını açıklar. Uygulama menüsü rolleri özel klavye davranışı beklentisi yaratır. Açılır bağlantı listesinde Tab gezinmesi korunmalı; düğme Enter ve Space ile çalışmalı; Escape ile kapatma ve odağı açan düğmeye döndürme davranışı planlanmalıdır.

Yalnızca aria-expanded eklemek açma ve kapatma işlemini gerçekleştirmez. Bu durumların kodla yönetilmesi, kapalı bağlantıların klavye akışında kalmaması ve yardımcı teknolojilerle denenmesi gerekir. Mobil menü tasarımını uygulamadan önce “Açıldı, kapandı, pencere genişledi” durumlarının her birinde odağın nerede kalacağını yazın.

Sayfanın üstünde sabit bir başlık varsa menüden sonraki ilk bağlantıya da dikkat edin. Odak teknik olarak taşınmış olsa bile bağlantı başlığın altında kalabilir. Testi yalnızca menü öğeleriyle sınırlamamak, kullanıcının gezinmeden asıl göreve geçerken karşılaşacağı engelleri de görünür kılar.

Bir ziyaretçi göreviyle test edin

Kontrol göreviniz şu olabilir: “Ana sayfadan hizmetlere git, bir alt hizmeti bul, sonra iletişim sayfasını aç.” Bu yolu fare kullanmadan tamamlayın. Ardından aynı adımları dar görünümde, sayfa büyütülmüşken ve ters yönde Shift+Tab kullanarak deneyin.

Sonuçları bağlantı bazında kaydedin: Odak görünmüyor mu, kapalı panelin içine mi giriyor, yoksa menüden çıkılamıyor mu? Böyle bir kayıt, “menü erişilebilir olsun” ifadesinden daha uygulanabilir bir düzeltme listesi üretir. Otomatik taramalar yardımcı olabilir; fakat gerçek gezinme yolunu tamamlamak hâlâ ayrı bir kontroldür.

Teknik kaynak kontrolü: 17 Ekim 2026.