Engelli Kullanıcılar İçin Erişilebilirlik: Uyumluluktan Kullanılabilirliğe

Erişilebilirlik denetiminden temiz raporla çıkan bir siteyi ekran okuyucuyla açıp beş dakika kullanmayı deneyin. Çoğu zaman karşınıza çıkan ilk engel o raporda hiç görünmez: alt metin vardır ama görselin ne anlattığını söylemez, her bileşene Tab ile ulaşılır ama odak sayfada gördüğünüz sırayla ilerlemez. Uyumluluk ile kullanılabilirlik ayrı iki şeydir ve engelli kullanıcının günü ikincisinde geçer.

Denetim listesi neyi ölçer, neyi ölçmez

Erişilebilirlik yazılarının çoğu "teknik uyum tek başına yetmez" cümlesiyle açılır, sonra baştan sona teknik uyum kalemlerinden oluşan bir liste verir. Çelişki, iki farklı sorunun karıştırılmasından çıkar. Denetim kalemi var mı diye sorar: alt niteliği dolu mu, kontrast oranı eşiği geçiyor mu, form alanının etiketi var mı. Kullanılabilirlik ise ne kadar sürdü, kaç yanlış denemeyle, kullanıcı görevi tamamlayabildi mi diye sorar.

İkisi arasındaki ilişki tek yönlüdür. Denetimden kalan bir sayfa neredeyse kesinlikle kullanılamaz durumdadır, ama denetimden geçmek kullanılabilir olmayı garanti etmez. Bu yüzden aşağıdaki bölümler tek tek kuralları saymak yerine, kuralın hangi noktada yetersiz kaldığını gösteriyor.

Klavye sırası, DOM sırasıdır

Tab tuşuyla gezinen kullanıcı sayfayı sizin tasarladığınız sırayla değil, kaynak koddaki sırayla dolaşır. Bu ayrım pratikte şurada patlar: CSS ile görsel düzeni değiştirmek odak sırasını değiştirmez. Flexbox'ta order vermek, row-reverse kullanmak ya da grid alanlarını farklı yerleştirmek, ekranda soldan sağa görünen üç butonu klavyede tamamen başka bir sırayla dolaştırabilir. Gören bir kullanıcı için sorun yoktur; klavyeyle ilerleyen kullanıcı için sayfa rastgele zıplar.

Bunu ölçmek için araç kurmana gerek yok: sayfayı aç, elini fareden çek, Tab'a basarak baştan sona git. Odağın kaybolduğu, ekranın görünmeyen bir yerine atladığı ya da geri dönemediğin ilk nokta, düzeltilecek ilk noktadır. Beş dakika sürer ve hiçbir otomatik denetim aynı bilgiyi vermez.

Aynı yerde üç yaygın hata var. Odak halkasını outline: none ile silmek, klavye kullanıcısının imlecini görünmez yapar; görsel kaygı varsa halkayı kaldırmak yerine :focus-visible ile kendi tasarımınızı verin. Pozitif tabindex değerleri sayfanın doğal sırasını bozar ve zamanla bakımı imkânsız hale gelir; ihtiyaç duyulan tek değer, doğal olarak odaklanamayan bir öğeyi sıraya sokan tabindex="0"'dır. Üçüncüsü modal pencereler: açıldığında odak içine alınmayan ve kapandığında geldiği yere geri bırakılmayan bir modal, klavye kullanıcısını arka plandaki sayfanın içinde kaybeder.

Kontrast: 4.5:1 nerede biter

WCAG'ın AA düzeyinde metin için istediği 4.5:1 oranı doğru bilinen ama eksik uygulanan bir eşiktir. Kural büyük metin için gevşer: yaklaşık 24 piksel ve üzeri normal metinde ya da 19 piksel civarındaki kalın metinde 3:1 yeterli sayılır. Ters yönde ise çoğu ekibin atladığı bir madde vardır: metin olmayan öğeler de kontrast ister. Form alanının kenarlığı, tek başına anlam taşıyan bir ikon, grafikteki çizgi rengi arka planla en az 3:1 tutmalıdır.

Pratikte gövde metni neredeyse her zaman geçer, sorun kenarlardadır. Açık gri yardım metinleri, kutunun içinde etiket görevi görmeye çalışan soluk placeholder yazıları, kenarlığı arka plandan zar zor ayrılan girdi alanları. Otomatik araçlar bunların bir kısmını yakalar, ama placeholder metnini ya da arka plan görseli üzerine binen yazıyı çoğu zaman ölçemez.

Alt metin: dolu alan değil, doğru bilgi

Alt metin tartışmasında en çok yanlış anlaşılan nokta, boş alt niteliğinin hata sanılmasıdır. Dekoratif bir ayraç, arka plan dokusu ya da yanındaki başlığı tekrar eden bir ikon için doğru cevap alt=""'dir; bu, ekran okuyucuya "burayı atla" der. Niteliği hiç yazmamak ise farklıdır, o zaman ekran okuyucu dosya adını okumaya başlar.

İkinci nokta, daha uzun alt metnin daha iyi olmadığıdır. Bir haber sayfasındaki fotoğrafın altına yazılan şiirsel manzara tarifi, sesle dinleyen kullanıcı için bilgi değil gecikmedir. Alt metin görselin görünüşünü değil, sayfadaki işlevini anlatmalıdır. Aynı ürün fotoğrafı liste sayfasında "lacivert erkek gömlek", detay sayfasında yaka dikişini gösteren yakın çekimse "gömleğin yaka dikişi yakın çekim" olur. Görsel bir bağlantının içindeyse alt metin görseli değil, bağlantının nereye gittiğini söyler.

Başlıklar ekran okuyucunun haritasıdır

Ekran okuyucu kullanan biri sayfayı baştan sona dinlemez. Tek tuşla başlıklar arasında atlar ya da tüm başlıkların listesini çıkarıp doğrudan istediği bölüme gider. Bu yüzden başlık etiketleri bir görünüm tercihi değil, sayfanın içindekiler tablosudur.

Buradaki hata iki yönde işler. Görsel olarak başlık gibi duran ama p ya da div ile yazılmış satırlar o listede hiç görünmez, bölümün tamamı erişilemez hale gelir. Tersine, sırf punto büyük görünsün diye seçilen bir h2 listeyi anlamsız kalabalıkla doldurur. Seviye atlamak da aynı haritayı bozar: h2'den doğrudan h4'e geçen bir sayfada kullanıcı arada bir bölüm kaçırdığını sanır. Aynı mantık nav, main, footer gibi bölge etiketleri için de geçerlidir; doğru kullanıldıklarında kullanıcı menüyü dinlemeden doğrudan içeriğe atlayabilir.

Formlar ve hata mesajları

Form alanının etiketi, for ve id ile alana programatik olarak bağlanmadıysa yoktur. Görsel olarak üstünde duran metin ekran okuyucu için başka bir alanın etiketi kadar uzaktır. Placeholder da etiket yerine geçmez: yazmaya başlayınca kaybolur, kontrastı genelde düşüktür ve kullanıcı alanın ne istediğini unuttuğunda geri getirmenin yolu yoktur.

Hata bildirimlerinde iki kural işe yarar. Hata yalnızca renkle anlatılmaz; kırmızı çerçeve renk körü kullanıcı için boş bir sinyaldir, yanına metin gerekir. Hata metni de alanın hemen yanında durmalı ve ne yapılacağını söylemelidir. "Geçersiz değer" yerine "Telefon numarasını başında sıfır olmadan, on hane girin" yazan bir mesaj, sadece erişilebilirliği değil form tamamlama oranını da düzeltir. Dokunma hedeflerinde ise WCAG 2.2 ile gelen 24x24 CSS piksellik asgari boyut iyi bir taban; motor becerisi kısıtlı kullanıcılar ve küçük ekranlar için genelde daha cömert davranmak gerekir.

Otomatik araç nereye kadar götürür

WAVE, axe ve Lighthouse gerçekten faydalıdır ve denetimi sürekli çalıştırmanın maliyeti düşüktür. Ama ne yaptıklarını doğru bilmek gerekir: bu araçlar makinece karar verilebilen kuralları kontrol eder. Alt niteliğinin varlığını görür, doğruluğunu göremez. Kontrast oranını hesaplar, başlık sırasının anlamlı olup olmadığını değerlendiremez. Etiketsiz form alanını bulur, hata mesajının anlaşılır olup olmadığını bilemez.

Bu yüzden otomatik denetimi kalite ölçüsü değil regresyon ağı olarak kullanın: derleme sürecine bağlayın, geçmiş bir kural yeniden bozulduğunda sizi uyarsın. Gerçek değerlendirme insanla yapılır. Ekran okuyucu kullanan bir kullanıcıyla yapılan tek oturum, otomatik denetimin haftalarca üreteceğinden daha fazlasını gösterir. Böyle bir kullanıcıya erişemiyorsanız, en azından NVDA ya da VoiceOver açıp kendi sayfanızda bir görevi ekrana bakmadan tamamlamayı deneyin. Deneyimin aynısı olmaz, ama hangi bilginin sesle hiç aktarılmadığını ilk beş dakikada anlarsınız.