Erişilebilirlik Talebini Paydaşlara Onaylatmak
Erişilebilirlik bütçesi iyi niyetle değil, sağlam bir gerekçeyle onaylanır. Sorun şu ki elinizdeki verinin çoğu ters yönde çalışır: erişilemeyen bir ürün, engelli kullanıcıyı kendi istatistiklerinden zaten silmiştir. Aşağıda, paydaş toplantısında gerçekten tutan argümanlarla tekrarlana tekrarlana etkisini yitirenleri ayırıyorum.
Genel istatistik toplantıda tutmuyor
Her altı kişiden birinin bir engelle yaşadığı, Dünya Sağlık Örgütü kaynaklı ve çok tekrarlanan bir rakam. Söylediğinizde kimse itiraz etmez. Kimse bütçe de açmaz. Çünkü masanın karşısındaki soru bu değil: o oranın ne kadarı bizim ürünümüze giriyor, girmeye çalışıp vazgeçiyor?
Rakam yanlış değil, kullanımı zayıf. Nüfus geneline ait bir oran, sizin kayıt formunuzla ilgili tek bir cümle söylemez.
“Bizim engelli kullanıcımız yok” cümlesindeki döngü
İlk duyulduğunda makul gelir: analitikte iz yoksa talep de yoktur. Ölçüm tarafından bakınca cümle kendi kuyruğunu ısırıyor. Ekran okuyucuyla geçilemeyen bir kayıt formu, ekran okuyucu kullananları veri setinden çoktan çıkarmıştır. Oradaki sıfır, talebin yokluğunu değil filtrenin çalıştığını gösterir.
Bunu tartışmak yerine ölçün. Kendi kayıt akışınızı fareye hiç dokunmadan, yalnızca klavyeyle tamamlamayı deneyin ve nerede takıldığınızı adım adım not edin. Bir saatlik iş. Çıktısı genel bir oran değil, doğrudan kendi ürününüzden çıkmış bir tıkanma listesi, ve toplantıda bütün nüfus istatistiklerinden daha hızlı iş görüyor.
Empati oturumu ile gerçek oturum aynı şey değil
Simülasyon gözlüğü, bulanıklaştırılmış ekran, gözü kapalı deneme gibi empati atölyelerini, ekran okuyucusunu yıllardır kullanan tek bir kişinin yaptığı gerçek oturumdan daha zayıf bulurum. Simülasyon engeli acemilikle karıştırır: katılımcı aracı beceremediği için zorlanır, çıkan tablo da olduğundan karamsar olur.
Gerçek kullanıcı tersini gösterir. NVDA'yı ya da VoiceOver'ı sizden hızlı kullanır, sayfayı başlıklara göre tarar, tam olarak sizin işaretlemenizin bozuk olduğu yerde durur. Odadaki herkesi ikna eden şey o duraklamadır, sunumdaki hiçbir slayt değil.
Maliyet argümanını gerekçesiyle kurun
“Sonradan düzeltmek pahalı” doğru bir cümle, ama gerekçesi söylenmediği için slogana dönüşmüş. Somut hali şöyle: form alanıyla etiketi arasındaki bağ tek bir bileşende kuruluyorsa düzeltme bir satır. Kırk ekranda kırk ayrı elle yazılmış form varsa aynı düzeltme kırk ayrı iş, kırk ayrı gözden geçirme, kırk ayrı regresyon riski demek. Maliyeti büyüten erişilebilirlik değil, işaretlemenin dağınıklığı.
Bu yüzden talebi ayrı bir erişilebilirlik projesi olarak değil, bileşen kütüphanesinin bakım kalemi olarak sunmak çok daha kolay geçiyor. Zaten onaylanmış bir bütçeye bağlanır, bir kere düzeltilen bileşen de bütün ekranlara kendiliğinden yayılır.
Otomatik denetleyiciler bu işin yalnızca bir kısmını yapar. axe ya da Lighthouse eksik alt metni, düşük kontrastı, etiketsiz alanı yakalar; odak sırasının kullanıcı için anlamsız olduğunu göremez. Onu klavyeyle gezerek siz görürsünüz. Pazarlama tarafındaki argümanlar için Deque'in iş gerekçesi derlemesi işe yarar bir başlangıç.
İlk projeyi dar tutun
Onay aldıysanız bütün siteyi taramakla başlamayın. Tek bir akış seçin, tercihen para ya da kayıt geçen bir tanesini.
- Akışı klavyeyle ve bir ekran okuyucuyla baştan sona geçin, kırılma noktalarını yazın.
- Kırılmaların kaçının ortak bileşenden geldiğini işaretleyin, sıralamayı buna göre yapın.
- Düzeltmeleri bileşen katmanında yapın, sayfa katmanında yamamayın.
- Aynı akışı bu kez gerçek bir kullanıcıyla tekrar geçin.
Dördüncü adım en çok atlanan adım, ve bir sonraki bütçeyi getiren adım da o. Paydaş itirazlarının daha uzun bir listesi için Smashing Magazine'deki derleme okunabilir.