Görevlerle ve küçük bir bilgi mimarisiyle başlayın
Bilgi mimarisi, içerik ve işlevlerin nasıl gruplanıp adlandırıldığını ve bağlandığını tanımlar. Ziyaretçi görevlerini listeleyin, sonra her görevin başlangıç sayfasını, bir sonraki sayfasını ve başarılı son durumunu eşleyin. Bu, bir menü öğesinin yararlı olup olmadığını veya ziyaretçilerin çözmesi gereken içsel bir etiketi gösterecektir. Birincil navigasyonu, bu görevleri başlatan bölümlere odaklı tutun.
Navigasyon bir site haritası değildir. GOV.UK, bir hizmetin her bölümünü değil, faydalı üst düzey bölümleri listelemeyi önerir. Bir yolculuk sıralıysa, küresel bir menüden çıkarım yapılmasını beklemek yerine, bunu içerikte veya görev listesinde gösterin.
Ziyaretçilerin aynı cevabı veya görevi beklediği sayfaları bir arada tutun; onları bir takımın sahip olduğu için değil.
Yoğun bir başlık yerine açılış sayfaları ve bağlamsal bağlantılar kullanarak ayrıntıya yer verin.
Hedefi tahmin ettiren etiketler kullanın
Bir etiket, takip edenler hakkında bir söz verir. Hedefle eşleşiyorsa “Pricing”, “Documentation”, “Get support” veya “Manage account” gibi tanıdık adları tercih edin. Ziyaretçilerin içeriği tahmin edemeyeceği sürece “Resources” veya “Explore” gibi belirsiz etiketlerden kaçının. Sözcük ve sıra tutarlılığını koruyun.
Google, bağlam dışı anlaşılabilir kısa ve ilgili bağlantı metinlerini önerir. Genel “buraya tıklayın” veya anahtar kelime yığını yapan bağlantılar ikisini de sağlamaz. Sadece simge içeren bir kontrolün, yaptığı eylemi tanımlayan erişilebilir bir adının olmasını sağlayın.
Hedef planlarsa “Learn more” yerine “View plans” kullanın.
Etkin hedefi görsel ve programatik olarak işaretleyin; W3C aria-current=page için açıklama sağlar.
Hedefleri taranabilir ve yapısal olarak açık yapın
Bir navigasyon hedefi normalde gerçek bir web adresine çözülen bir HTML anchor ile, yani bir href içeren bir bağlantı olmalıdır. Google, render edilmiş işaretleme bu yapıyı koruduğu sürece dinamik olarak eklenen anchor'ların da genellikle taranabilir olduğunu belirtir. Bir tıklama işleyicisi veya özel öznitelik tek başına güvenilir bir ikame değildir. Çerçeve kaynak koduna değil, render edilmiş çıktıya bakın.
Ana navigasyon etrafında anlamsal yapı kullanın. W3C, nav öğesini ve olağan site navigasyonu için bir listeyi önerir. Bir sayfada birkaç navigasyon bölgesi varsa, ekran okuyucu kullanıcılarının birincil navigasyonu ayırt edebilmesi için her birini etiketleyin; footer veya yerel navigasyonu ayırt etmek önemlidir.
Önemli masaüstü ve mobil hedeflerin istemci tarafı renderinden sonra anchor ve href değerlerine sahip olduğunu doğrulayın.
URL Inspection Google’ın tarama, dizinleme ve sunma bilgilerini verir; bu ziyaretçilerin bir sayfayı bulabildiğini kanıtlamaz.
Mobil menüyü eksiksiz bir etkileşim olarak tasarlayın
Uyumlu (responsive) navigasyon daralabilir, ancak kalan hedefler ekran boyutları arasında aynı sözcükleri, sırayı ve hedefi korumalıdır. W3C, alt navigasyondaki öğelerin daraltılmasına veya gizlenmesine izin verirken tutarlılık çağrısında bulunur. Başlık kalabalık olduğu için kritik bir yolu yalnızca masaüstüne özel yapmayın; önceliği düşük içeriği yeniden yerleştirin veya hiyerarşiyi yeniden değerlendirin.
Göster/gizle menüsü için bağlantı grubunu kontrol eden bir buton kullanın ve açık olup olmadığını iletin. W3C’nin disclosure-navigation örneği aria-expanded ve aria-controls kullanır ve Tab, Shift+Tab ve Escape davranışlarını belgelendirir. Bu örnek öğreticidir; kendi bileşeninizi hedef kitlenizin kullandığı kombinasyonlarla test edin.
Hem ana sayfa bağlantısına hem de alt linkleri açan kontrole ihtiyaç varsa, sayfa bağlantısını genişletme kontrolünden ayırt edin.
İmleç hover'ıyla açılan her şey klavye odaklanması ve dokunma ile de keşfedilebilir olmalıdır.
Yönlendirme ve klavye ile yolculuğu destekleyin
Klavye erişimi bir son rötuş değildir. WCAG 2.1 Başarı Kriteri 2.1.1, yol-bağımlı girişler dışında işlevselliğin klavye arayüzüyle işletilebilir olmasını gerektirir. Bir başlıkta ziyaretçiler Kontrol tuşları arasında Tab ile gezinebilmeli, odak görünür olmalı, bağlantıları ve butonları etkinleştirebilmeli ve tuzağa düşmeden uzaklaşabilmelidir.
Tekrarlanan başlık bağlantıları sayfaların gezinmesini yavaşlatabilir. Başlangıca yakın bir atla bağlantısı (skip link) klavye kullanıcılarına ana içeriğe bir yol sağlar. GOV.UK bunun klavye kullanımı etkinleşene kadar görsel olarak gizlendiğini açıklar. Hedefin anlamlı bir yere indiğini test edin.
Tarayıcı odak göstergesini net bir alternatif olmadan kaldırmayın; yakınlaştırıldığında da görünür kalmalıdır.
Başlıktan hedef sayfaya Tab, Shift+Tab, Enter, Space ve Escape ile geçiş yapın.
Yayın öncesi ve sonrası bulunabilirliği test edin
Temsilci kişilerden, iptal yönergelerini bulma veya planları karşılaştırma gibi gerçekçi bir görevi tamamlamalarını isteyin. Hangi hedefe gitmeyi beklediklerini, hangi etiketleri yanlış okuduklarını ve navigasyon başarısız olunca aramaya başvurup başvurmadıklarını izleyin. Onları hedef etiketine yönlendirmeyin. Her engeli ve onu giderecek en küçük değişikliği kaydedin.
Görev testlerini teknik kontrollerle eşleştirin. W3C’nin Easy Checks’i fare olmadan test etmeyi, odak görünürlüğünü, sekme sırasını, klavye tuzaklarını ve açılır menüleri kontrol etmeyi önerir. Temel görevleri dar ekranlarda ve daha büyük metin boyutlarında tekrar edin. Otomatik kontroller işaretleme sorunlarını tespit edebilir, ancak bir etiketin mantıklı olduğunu kanıtlayamaz.
Testten önce amaçlanan bitiş noktasını ve desteklenen cihaz veya giriş yöntemini kaydedin.
Eski ve yeni rotayı aynı görevler karşısında test edin; paydaş tercihlerine yaslanmayın.
Navigasyon değişikliklerini kullanılabilirlik-duyarlı sürümler olarak ele alın
Bir başlık yüklenmiş olsa bile kritik bir yol aslında kullanılamaz durumda olabilir: bir ödeme sayfası, oturum açma, destek rotası veya dokümantasyon sayfası bozuk bir durum, eski bağlantı veya yanlış yönlendirme nedeniyle erişilemeyebilir. Yayınlamadan önce kritik hedeflerin envanterini çıkarın, masaüstü ve mobil rotaları test edin ve render edilmiş bağlantıların hedef sayfaya ulaştığını doğrulayın. Yetkili ortamları kimlik doğrulamalı veya bölgesel yollar için kullanın.
SIU’nun rolü proaktif düzeltmedir: bir preflight çalıştırın, dağıtım sonrası temel yolları doğrulayın ve düzeltmeyi geri alınabilir kılın. Menü yapılandırmasını versiyonlayın, geri almayı kimin yapabileceğini adlandırın ve geri yüklenen yolları doğrulayın. Bu, sürüm etkisini sınırlar; kullanılabilirlik araştırmasının veya canlı durum izlemenin yerini almaz.
Kritik bir hedef eksik, yanlış veya klavye ve dokunmayla ulaşılamaz durumdaysa yayını engelleyin.
Yapıyı yeniden düzenlemeden önce önceki yapılandırmayı, sahibini, tetikleyiciyi ve doğrulama adımlarını belgeleyin.