Erişilebilirlik Denetimini Geçen Site Neden Kullanılamaz?
Bir sayfa bütün otomatik erişilebilirlik kontrollerinden geçebilir ve ekran okuyucu kullanan biri yine de fatura ekranına ulaşamayabilir. Bu bir çelişki değil, aracın ne ölçtüğüyle ilgili bir sınır. Denetleyici kodda hesaplanabilen şeye bakar; kullanıcı ise görevini tamamlayıp tamamlayamadığına.
Denetim aracı neyi ölçer?
Otomatik denetleyicilerin ölçtüğü şeyler deterministiktir. Bir öğenin etiketi var mı, metinle arka plan arasındaki kontrast oranı hesaplanabiliyor mu, başlık seviyeleri atlamadan iniyor mu, form alanının bağlı bir label öğesi var mı. Bunların hepsi DOM üzerinden hesaplanır ve bu alanda araçlar gerçekten güvenilirdir.
Ölçemedikleri şey anlamdır. alt="resim1.png" yazan bir görsel testten geçer, ekran okuyucuda "resim bir nokta png" diye okunur. Başlığı Bölüm 2 olan bir h2 hiyerarşi kontrolünü geçer, sayfayı başlıklara bakarak tarayan kullanıcıya hiçbir şey söylemez. Aynısı aria-label="tıkla" için de geçerli.
Aradaki fark tek cümleyle özetlenebilir: araç bir şeyin var olduğunu doğrulayabilir, uygun olduğunu doğrulayamaz. Bu yüzden bir denetim skorunu erişilebilirlik hedefi olarak koymam; skor bir alt sınırdır, üst sınır değil.
Görev tabanlı değerlendirme nasıl kurulur?
Skorun yerine koyabileceğiniz ölçü, kullanıcının işini bitirip bitiremediğidir. Kurulumu şöyle işliyor.
- Sitenin gerçekten var olma sebebi olan üç beş görevi yazın: faturayı görüntüle, izin talebi oluştur, randevuyu iptal et. Sayfa değil görev.
- Her görevi fareye hiç dokunmadan, yalnızca klavyeyle baştan sona yapın.
- Aynı görevleri bir ekran okuyucu açıkken tekrarlayın. Ekranı kapatmanız gerekmiyor, ama sesin söylediğiyle ekranda gördüğünüzün ayrıştığı yerleri not edin.
- Sonucu ikili kaydedin: tamamlandı ya da tamamlanmadı. Yanına kaç adım sürdüğünü ve nerede geri dönüldüğünü ekleyin.
Böyle bir tablo "erişilebilirlik yüzdesi"nden daha az yanıltıcıdır, çünkü kaçırdığınız şeyi saklayamaz. Bir görev tamamlanamıyorsa, geri kalan yüz kontrolün geçmiş olması durumu değiştirmiyor.
Klavyeyle geçilen yolu izleyin
Odak sırası, görsel sıra değil DOM sırasıdır. Bir bloğu CSS ile sağa taşıdığınızda görsel akış değişir, odak akışı değişmez; kullanıcı sayfanın altındaki bir öğeye atlar ve nerede olduğunu kaybeder. Aynı şekilde açılır pencerelerde odak içeride tutulmuyorsa, kullanıcı arkadaki sayfada sekme sekme dolaşır ve kapatma butonunu hiç bulamaz.
Odak halkasını estetik kaygıyla kaldırmak da bu kategoride. Görünmeyen odak, klavye kullanıcısı için imleci olmayan bir ekran demektir.
"İçeriğe atla" bağlantısı bunların en ucuzu: bir a etiketi, bir id ve odaklanınca görünür hale gelen birkaç satır CSS. Üçüncü parti bir erişilebilirlik eklentisine gerek yok, o eklentiler zaten çoğunlukla üstüne bir katman daha koyup sorunu büyütüyor.
Testi kimlerle yapmalı?
Yardımcı teknolojiyi hiç kullanmamış birine ekran okuyucu açıp görev vermek test değildir; o kişinin öğrenme eğrisini ölçersiniz, sitenizi değil. Deneyimli bir kullanıcı ekran okuyucuyu sizin takip edemeyeceğiniz bir hızda dinler, kısayolları ezbere bilir ve sayfayı başlık listesinden tarar. Sizin dakikalarca dolaşarak bulduğunuz bir sorunu o üç saniyede yakalar.
Bu yüzden test, kendi cihazını ve kendi ayarlarını getiren gerçek kullanıcılarla yapılır. Farklı kısıt türlerinden dört beş kişi, aynı görevleri kendi düzenlerinde denesin. Az görme, işitme, motor kısıt ve bilişsel yük birbirinden farklı sorunlar çıkarır; hepsini tek bir profille temsil etmek yaygın bir hata.
Kalıcı olmayan kısıtlar
Kısıt her zaman kalıcı değil. Kolu alçıda olan biri de tek elle yazıyor, güneş altında telefona bakan biri de kontrast sorunu yaşıyor, yorgun bir kullanıcı da karmaşık bir formda kayboluyor. Erişilebilirlik için yaptığınız işin büyük kısmı aslında bu geniş gruba hizmet ediyor, ki bu da bütçe tartışmasında en işe yarar argüman.