Sabit başlık klavyeyle seçilen alanı gizliyor mu?
Bir web sayfasında fareyle her şey kullanılabilir görünürken klavyeyle ilerleyen kişinin seçtiği alan sabit başlığın arkasına girebilir. Kullanıcı hangi bağlantıda olduğunu kaybeder veya yanlışlıkla başka bir işlem başlatır. Bu rehber bütün erişilebilirlik ölçütlerini denetlemek yerine tek bir soruya odaklanır: klavye odağını alan kontrol, sayfanın kendi sabit katmanları tarafından gizleniyor mu? Kontrolü gerçek içerik ve farklı ekran koşullarıyla yapmak gerekir.
1. Odak sırasını görünür alanla birlikte izleyin
Sayfayı yeniden açıp fareyi bir kenara bırakın. Tab tuşuyla bağlantılar ve form alanları arasında ilerleyin; Shift+Tab ile geri dönün. Her adımda hangi kontrolün odakta olduğunu ve bu kontrolün görünür olup olmadığını kaydedin. Sadece sayfanın en üstünü denemek yeterli değildir. Uzun bir hizmet açıklamasının ortasında, formun başında ve footer yakınında aynı denemeyi yapın. Başlık kaydırmayla küçülüyor veya sonradan sabitleniyorsa her iki durumu da inceleyin. Odak çerçevesinin hiç görünmemesi ayrı bir sorun olarak kaydedilmelidir.
2. Minimum koşulla daha iyi deneyimi ayırın
W3C’nin WCAG 2.2 Focus Not Obscured (Minimum) açıklaması, odaklanan bileşenin yazar tarafından oluşturulan içerik nedeniyle tamamen gizlenmemesini ister. Kısmen görünmek bu minimum koşulu karşılayabilir; bileşenin bütünüyle görülebilmesi daha iyi bir kullanım hedefidir. Örneğin bağlantının yalnız ince bir kenarı görünürken kullanıcı hangi metni seçtiğini okuyamayabilir. Bu yüzden ekip kabul ölçütünü yalnız “tamamen kaybolmuyor” diye belirlemek zorunda değildir. İncelenen kontrolün metni, odak göstergesi ve yapılacak işlem birlikte anlaşılabiliyor mu, bunu da sorun.
3. Sabit katmanların birlikte kapladığı alanı ölçün
Varsayımsal bir teklif sayfasında üstte sabit menü, altta iletişim bandı bulunsun. Tek başlarına küçük görünen bu katmanlar kısa bir pencerede içerik alanını daraltabilir. Mobil yatay görünümü, büyütülmüş metni ve açık bildirim bantlarını da deneyin. Bütün sabit öğeleri aynı anda etkinleştirerek form alanlarına ilerleyin. Sorunu yalnız masaüstü yüksekliğine göre çözmek başka bir ekranda yeni çakışma doğurabilir. İletişim düğmesinin sürekli görünmesi, müşterinin doldurmak istediği alanı örtüyorsa yerleşim kararını yeniden değerlendirin; gerekli bilgiyi erişilemez bırakmayın.
4. Boşluk ayarı yardımcıdır; sonucu tekrar deneyin
Geliştirici, gerçek kaydırma alanında scroll-padding-top gibi bir ayarla sabit üst katman için boşluk ayırmayı değerlendirebilir. MDN bu özelliği görünür hedef bölgesinin üst boşluğunu tanımlayan bir kontrol olarak açıklar. Ancak tek bir CSS satırını her durumda çalışan çözüm gibi kabul etmeyin. İç içe kaydırma alanları, değişken başlık yüksekliği ve farklı odak hareketleri test edilmelidir. Gerekirse sabitlik davranışını azaltın veya katmanın boyutunu değiştirin. Çözümden sonra hem ileri hem geri klavye sırasını, form doğrulama mesajları açıkken de yeniden kontrol edin.
5. Kanıtı belirli kontrol ve ekran koşuluyla kaydedin
Hata kaydına sayfa adresini, odaklanan alanın adını, gezinme yönünü ve ekran boyutunu ekleyin. Önceki ve sonraki görüntü aynı koşulda karşılaştırılabilsin. Düzeltmeyi yalnız başlığın estetik görünümüyle onaylamayın; klavyeyle işlemi tamamlamayı deneyin. Bu sınırlı kontrol bütün sitenin WCAG uyumlu olduğunu kanıtlamaz. Web tasarım çalışmasında kabul senaryolarına eklenebilir; sabit iletişim alanının yerleşimi için mobil sabit eylem rehberi de kullanılabilir. İki karar birbirini tamamlar: düğmenin nerede bulunacağı ve diğer kontrolleri gizleyip gizlemeyeceği ayrı ayrı incelenir.
Sık sorulan sorular
Kontrolün küçük bir bölümü görünüyorsa sorun bitmiş midir?
WCAG’nin bu minimum ölçütü tamamen gizlenmeyi ele alır. Kullanıcı için hedefin, metnin ve odak göstergesinin bütünüyle anlaşılır olması daha iyi bir kabul hedefidir.
scroll-padding-top eklemek yeterli mi?
Her durumda değil. Gerçek kaydırma alanı, başlığın değişen yüksekliği ve ileri/geri klavye gezinmesiyle sonuç tekrar denenmelidir.