Mobilde Ekran Okuyucu: Erişilebilirlik Tam Olarak Nerede Kırılıyor?

Ekran okuyucu kullanıcısının mobildeki sorunu çoğu zaman "içeriği baştan sona dinlemek zorunda olmak" diye anlatılır. Oysa VoiceOver ve TalkBack yıllardır başlıktan başlığa, bağlantıdan bağlantıya atlamayı biliyor. Sorun atlama imkânının olmaması, kodda atlanacak bir yapının bulunmaması.

"Sırayla dinlemek zorunda" iddiası neyi gizliyor?

iOS'ta rotor, Android'de okuma denetimleri ekran okuyucunun gezinme birimini değiştirir: kullanıcı birimi "başlıklar" yapar, sonra yukarı-aşağı kaydırmayla sayfanın iskeletini saniyeler içinde geçer. Yani tarama yeteneği zaten orada. Çalışmadığı durum şu: başlık görsel olarak başlık, kodda değil.

<div class="baslik"> içine 24 piksel kalın yazı koyduğunuzda göz onu başlık diye okur, rotor hiç görmez. Aynı sayfada altı tane böyle sahte başlık varsa, rotor listesi boş döner ve kullanıcı gerçekten baştan sona dinlemeye mahkûm kalır. Kaynak metinlerin "ardışık erişim" dediği şey genelde bu: platformun kısıtı değil, işaretlemenin eksiği.

Peki başlıklar doğru etiketlerle yazıldığında iş biter mi? Pek değil. Seviye atlamaları (h2'den sonra h4, sonra geri h3) rotor listesini düzleştirir; kullanıcı hiyerarşiyi duymaz, art arda sıralanmış on dört satır duyar. Başlık listesini bir kez sesli dinleyin, sayfanın içindekiler tablosu gibi okunmuyorsa yapı bozuk demektir.

Odak açıldıktan sonra nereye gidiyor?

Mobilde en çok kaybedilen şey odak. Alt sayfa açılıyor, filtre paneli yukarıdan iniyor, tek sayfa uygulamada rota değişiyor. Görsel olarak her şey yerinde; ekran okuyucu odağı ise hâlâ bir önceki ekranın beşinci bağlantısında duruyor ya da doğrudan body'ye düşmüş durumda. Kullanıcı kaydırdığında artık var olmayan bir bağlamın kalıntılarını duyar.

Burada iki yaklaşım yarışıyor: odağı yeni alana elle taşımak, ya da bir aria-live bölgesiyle değişikliği duyurmak. Rota değişimi gibi bağlamın tümden değiştiği durumlarda canlı bölge duyurusu yetersiz kalıyor, çünkü duyuru bitince kullanıcı yine nerede olduğunu bilmiyor. Yeni ekranın başlığına tabindex="-1" ver, açılış anında ona focus() çağır, gezinme oradan devam etsin. Bunu üçüncü parti bir erişilebilirlik eklentisinden beklemeyi bırak: odağı taşımak iki satırlık iş, eklenti ise aynı bozuk DOM'un üstüne ikinci bir gezinme katmanı bindirmekten başka şey yapmıyor.

Diyalog kapanırken de aynı disiplin geçerli: odak, diyaloğu açan düğmeye geri dönmeli. Dönmezse kullanıcı listenin başına savrulur ve kaldığı yere ulaşmak için baştan kaydırır.

Etiketin ilk kelimesi neden bu kadar belirleyici?

Ekran okuyucu bağlantıları liste halinde okurken yalnızca erişilebilir adı duyurur, çevresindeki görsel bağlamı duyurmaz. Sekiz ürün kartının hepsinde "Daha fazla bilgi" yazıyorsa, liste sekiz özdeş satırdan oluşur.

Kaynak metinlerin klasik çözümü, etiketin önüne bağlam eklemek: "Ürün Detayları, Daha fazla bilgi". Burada küçük bir çelişki var, çünkü aynı metinler bir paragraf sonra etiketlerin kısa tutulmasını söylüyor. İkisi birlikte uygulanamaz. Tercih edilecek yol, bağlamı öne eklemek değil, bağlantı metnini kendi başına yeterli hale getirmek: "Daha fazla bilgi" yerine doğrudan "Ürün detayları".

Görünen metinle erişilebilir adı birbirinden ayırmanın ayrı bir maliyeti de var. Sesli kontrol kullanan biri ekranda gördüğü kelimeyi söyleyerek düğmeye basar; aria-label ile adı değiştirdiğinizde o kişi için düğme kaybolur. Görünen yazıyı düzeltmek, görünmeyen bir etiketle yamamaktan daha çok kişiye hizmet ediyor.

Jestler ekran okuyucu açıkken aynı anlama gelmiyor

Mobil erişilebilirlikte en sık atlanan nokta bu. VoiceOver veya TalkBack açıkken tek parmak kaydırma artık "sayfayı kaydır" değil, "sonraki öğeye geç" demek. Dokunma "bas" değil, "seç"; basmak için çift dokunma gerekiyor.

Sonucu şu: kendi jestinizi icat ettiyseniz, ekran okuyucu kullanıcısı için o işlev yok sayılır. Yana kaydırarak silinen liste satırı, parmakla çevrilen galeri, aşağı çekerek yenilenen akış. Hepsinin görünür bir düğme karşılığı olmak zorunda. Galeride ileri-geri düğmeleri, liste satırında bir eylem menüsü, yenileme için bir "Yenile" düğmesi.

Hedef boyutu da aynı hikâyenin parçası. WCAG 2.2, 2.5.8 ölçütüyle en az 24x24 CSS pikseli şart koşuyor (WCAG belgeleri), Apple'ın kendi kılavuzu 44 punto öneriyor. Motor becerisi kısıtlı bir kullanıcı için 24, çoğu zaman sınırda bir sayı; 44'ü hedeflemek daha güvenli.

Örtü katmanları neyi çözüyor, neyi erteliyor?

Siteye eklenen erişilebilirlik widget'ları genelde kendi menüsünü, kendi kontrast anahtarını, kendi yazı tipi büyütücüsünü getiriyor. Ekran okuyucu kullanan biri ise bu ayarları işletim sistemi düzeyinde yıllar önce yapmış ve her uygulamada aynı şekilde çalışmasını bekliyor. Sayfaya inen widget, ona yardımcı olmak yerine gezinme ağacına fazladan bir dal ekliyor.

Daha sinsi tarafı, aylık abonelik ödenince işin bitmiş sayılması. Oysa eksik olan şey hiç değişmedi: div ile yapılmış düğmeler, etiketsiz form alanları, odağı yöneten kod. Örtü bunları gizler, kaldırmaz.

Otomatik denetim nereye kadar?

axe ya da Lighthouse gibi araçlar eksik alt metnini, düşük kontrastı, etiketsiz input'u güvenilir biçimde yakalar. Yakalayamadıkları şey anlam: odak sırasının mantıklı olup olmadığı, duyurulan metnin doğru bilgiyi verip vermediği, başlık hiyerarşisinin sayfanın yapısıyla örtüşüp örtüşmediği.

En ucuz gerçek test, kendi telefonunuzda ekran okuyucuyu açıp ekranı kapatmak ve bir işi baştan sona bitirmeye çalışmaktır. Sepete ürün ekleyin, formu doldurun, hata mesajını bulun. On dakika içinde, otomatik denetimin yeşil verdiği sayfada en az bir çıkmaz sokak bulacaksınız. Bunu bulmak için engelli kullanıcı araştırmasına bütçe ayırmanız gerekmiyor; bulduktan sonra ne yapacağınıza karar vermek için gerekiyor.