Dokunmatik Ekranlarda Ekran Okuyucu Deneyimini Bozan Kararlar
Ekran okuyucuyla kullanılan bir arayüz, görsel arayüzün sesli anlatımı değildir, ayrı bir gezinme modelidir. Dokunmatik cihazda bu model tamamen jestlerin üzerine kuruludur ve eklediğin her özel jest onunla çakışma riski taşır. Aşağıdakiler, TalkBack ya da VoiceOver açılana kadar sorunsuz görünen kararlar.
Jestler ekran okuyucunundur, uygulamanın değil
TalkBack veya VoiceOver açıkken dokunma olayları önce ekran okuyucuya gider. Tek dokunuş öğeyi seçip okur, çift dokunuş onu etkinleştirir, tek parmakla sağa kaydırma sonraki öğeye geçer, iki parmakla aşağı kaydırma sayfanın tamamını okutur, üç parmak hareketi sayfayı kaydırır. Bunun doğrudan sonucu şudur: kendi yazdığın kaydırma jesti ekran okuyucu açıkken hiç tetiklenmez.
Yani "listede sola kaydırınca satır silinir" tasarımı, ekran okuyucu kullanıcısı için var olmayan bir özelliktir. Silme eylemini ayrıca görünür bir düğme olarak ya da platformun özel eylem mekanizmasıyla (iOS tarafında custom actions, Android tarafında accessibility actions) sunmak zorundasın. Bu bir iyileştirme değil, eksik kalmış işlevin tamamlanmasıdır.
Her görsele alt metin yazmak deneyimi kötüleştirir
İki yaygın tavsiye yan yana konduğunda çelişir: "içeriği sadeleştir, her fazladan kelime dinleme süresidir" ve "bütün görsellere alternatif metin ekle". Dekoratif bir ayraç çizgisine "dekoratif çizgi" yazdığında ikinci kuralı yerine getirip birincisini çiğnemiş olursun.
Doğrusu ayrımı yapmaktır. Görsel bilgi taşıyorsa alt metin bilgiyi anlatır, görselin kendisini değil: bir grafikte "çubuk grafik" değil, grafiğin gösterdiği sonuç yazılır. Görsel süslemeyse alt niteliği boş bırakılır, ekran okuyucu onu tamamen atlar. Boş bırakmakla niteliği hiç yazmamak aynı şey değildir, nitelik yoksa bazı ekran okuyucular dosya adını okumaya başlar.
Dokunma hedefi ve görünen etiket
WCAG 2.2'de dokunma hedefleri için asgari ölçü 24x24 CSS pikselidir (ölçüt 2.5.8), gelişmiş seviyede 44x44 (ölçüt 2.5.5). 24 bir alt sınırdır, hedef değil. Sık kullanılan eylemlerde 44'ü baz al.
Daha sinsi olan kural etiketle ilgilidir. Bir düğmenin üstünde "Gönder" yazıyorsa erişilebilir adı da bu metni içermelidir (ölçüt 2.5.3). aria-label ile üstüne "Formu tamamla ve gönder" yazdığında ekran okuyucu kullanıcısı bir şey kaybetmez, ama sesle komut veren kullanıcı "Gönder'e dokun" dediğinde eşleşme kurulamaz ve düğme çalışmaz. aria-label görünen metni zenginleştirmek için değil, görünen metnin bulunmadığı yerde kullanılır.
Odak nereye gidiyor
Görsel arayüzde modal açıldığında kullanıcı ona bakar. Ekran okuyucuda böyle bir şey olmaz: odak taşınmazsa kullanıcı hâlâ arkadaki sayfadadır ve arka plan gizlenmediyse okumaya oradan devam eder. Bir projede modal açıldıktan sonra odağın arkadaki listede kaldığını ancak TalkBack açıkken fark ettim.
Kural nettir: açılan katmana odağı taşı, arkadaki içeriği inert ya da aria-hidden ile kapat, katman kapandığında odağı onu açan öğeye geri ver. Aynı şey sayfa içi yönlendirmelerde de geçerlidir. Tek sayfa uygulamalarında içerik değişip odak ve sayfa başlığı olduğu yerde kalırsa, kullanıcı yeni bir şey geldiğini anlamaz.
Otomatik denetim yetmez
Otomatik araçlar eksik alt niteliğini, düşük kontrastı, atlanmış başlık seviyelerini bulur. Etiketin doğru olup olmadığını bulamaz, çünkü bu bir anlam meselesidir. "Buton" adlı bir düğme denetimden temiz geçer, kullanıcıya hiçbir şey söylemez.
Erişilebilirlik iddiasının kodda karşılığı olduğunu doğrulamanın tek yolu aracı açıp kullanmaktır. Ekranı kapat, TalkBack ya da VoiceOver ile ana akışı baştan sona geç. Bu deneme yarım saat sürer ve denetim raporunun göremediği ne varsa ilk beş dakikada ortaya çıkarır.