Erişilebilir Web Tasarımı: Önce Neyi Düzeltmeli
Erişilebilirlik işleri genelde yapılacaklar listesinin en sonuna yazıldığı için hiç yapılmıyor. Oysa listenin tamamını aynı anda bitirmek gerekmez. Birkaç düzeltme, kullanıcıların gerçekten takıldığı engellerin büyük kısmını ortadan kaldırır. Aşağıdakiler, hangi işin hangi sırayla yapılmaya değdiği.
Önce ekran okuyucu ve klavye
Bir arayüzü gözle kullanan kişi, kötü etiketlenmiş bir butonu ikonundan, konumundan, rengindeki tanıdıklıktan çıkarır. Ekran okuyucuyla gezen kişinin elinde tek kanal vardır: metin ve odak sırası. Bu yüzden aynı hata iki kullanıcıda çok farklı sonuç verir, birinde yavaşlama, diğerinde tam durma.
İyi haber, bu tarafın düzeltmelerinin ucuz olması. Doğru etiket, doğru öğe, öngörülebilir odak sırası. Bunların çoğu yeni bir tasarım değil, mevcut işaretlemenin düzeltilmesi.
ALT metni işlevi anlatır
Alt metnin işi, görselin sayfada ne yaptığını söylemek. Bu üç duruma göre değişir:
- Görsel bilgi taşıyorsa o bilgiyi yaz. Bir grafikte önemli olan grafiğin varlığı değil, gösterdiği eğilimdir.
- Görsel yalnızca dekoratifse boş bırak (alt=""), böylece ekran okuyucu onu atlar. Boş alt metin, eksik alt metinle aynı şey değildir.
- Görsel bir bağlantının içindeyse alt metin bağlantının nereye gittiğini söyler, resmin neye benzediğini değil.
Alt metne SEO gerekçesiyle anahtar kelime doldurmak eski bir alışkanlık ve iki tarafa da zarar veriyor: ekran okuyucu kullanıcısı anlamsız bir kelime dizisi dinliyor, arama motoru da bunu yıllardır kalite sinyali saymıyor. Açıklama gerçekçiyse anahtar kelimeyi zaten içerir.
Menüde önce doğru öğe, sonra ARIA
Tıklanabilir div, erişilebilirlik hatalarının en yaygın kaynağı. Klavyeyle odaklanılmaz, Enter ile tetiklenmez, ekran okuyucuya kendini buton diye tanıtmaz. Aynı öğeyi button olarak yazdığında bu davranışların üçü de tarayıcıdan hazır gelir.
ARIA'yı sonra düşün. W3C'nin kendi ilk kuralı, uygun bir HTML öğesi varken ARIA kullanmamak yönünde. Yanlış rol, hiç rol yazmamaktan daha kötü sonuç veriyor, çünkü ekran okuyucu artık tarayıcının doğru varsayımını değil senin yanlış beyanını okuyor. Hamburger menüde ihtiyacın olan genelde iki şey: butonun erişilebilir bir adı ve aria-expanded durumunun açılıp kapandıkça güncellenmesi.
DOM sırası meselesi yanlış kurulmuş
Yaygın tavsiye şudur: önemli içeriği kodun başına koy, çünkü ekran okuyucu sayfayı yukarıdan aşağı okur. Bu tarif, kullanıcının sayfayı baştan sona dinlediğini varsayıyor. Gerçekte deneyimli ekran okuyucu kullanıcısı başlık listesinden, işaret bölgelerinden ve bağlantı listesinden atlayarak ilerler. Yani iletişim bilgisini yukarı taşımak değil, onu bulunabilir bir h2 altına koymak işe yarar.
DOM sırasının asıl önemli olduğu yer başka: klavye odağı. CSS ile görsel sırayı değiştirdiğinde (flex order, grid yerleşimi, mutlak konumlandırma) odak hâlâ kaynak sırasını izler. Sonuç, ekranın altındaki bir öğeye odaklanmış ama görsel olarak yukarıda duran bir kullanıcı. Bunu yakalamanın yolu basit: sayfayı yalnızca Tab tuşuyla baştan sona gez, odak halkasının nereye gittiğini izle. Beş dakikalık iş, otomatik araçların çoğunun göremediği hatayı çıkarır.
Yakınlaştırmayı kapatma
Viewport meta etiketinde user-scalable=no ya da düşük bir maximum-scale değeri hâlâ çok sayıda temada duruyor. Az gören kullanıcı için bu, sayfanın kullanılamaz olması demek. iOS Safari bu kısıtı bir süredir yok sayıyor, Android tarafında ise etkisini sürdürüyor, dolayısıyla test ettiğin cihaza göre sorunu hiç görmeyebilirsin. Etiketten bu iki parçayı sil, arkasında savunulabilir bir gerekçe yok.
Otomatik denetim nerede biter
Otomatik araçlar yalnızca makinenin karar verebileceği kuralları yakalar: yetersiz kontrast oranı, eksik alt özniteliği, etiketsiz form alanı, tekrarlanan id. Alt metnin doğru olup olmadığına hiçbir araç karar veremez. "resim1.jpg" de geçerli bir alt metindir ve denetimden temiz geçer.
Yine de bu ucuz katmanı atlamanın anlamı yok. Kontrast ve eksik etiket denetimi için ayrı bir hizmete abone olmana gerek yok, axe-core'u test paketine ekleyip CI'da çalıştırırsın, kontrast hatası build'i düşürür ve sorun daha kod incelemesine gelmeden kapanır. Geriye kalanı, yani gerçek kullanımı, insanla test edersin. Ekran okuyucu kullanan birinin sitende bir işi baştan sona tamamlamasını izlemek, kontrol listelerinin aylarca göstermediğini on dakikada gösterir.
Mobili ayrı test et
Mobil düzen, masaüstünde olmayan iki risk getiriyor. Birincisi dar ekranda katlanan ya da gizlenen içerik: display:none ile gizlenen bir bölüm ekran okuyucudan da kaybolur, oysa amaç yalnızca görsel sadeleştirmeydi. İkincisi dokunma hedefleri; masaüstünde imleçle rahat vurulan yirmi piksellik bir ikon, parmakla ıskalanır.
VoiceOver ve TalkBack'in gezinme jestleri masaüstü ekran okuyucularından farklı çalışır. Masaüstünde temiz çıkan bir akışın mobilde tıkanması bu yüzden sık görülür, ayrı bir tur gerekiyor.
Kaynaklar