Erişilebilirliği test etmek

Kısa cevap

Otomatik erişilebilirlik araçları, kodda okunabilen ve tek bir kuralla karar verilebilen sorunları hızlı bulur: tanımlı bir zemin rengi üzerindeki metnin kontrastı, alternatif metni olmayan bir görsel, etiketi olmayan bir form alanı. Bir fotoğrafın üzerindeki yazının gerçekte ne kadar okunduğunu, bir bilginin yalnız renkle verilip verilmediğini, bir hata cümlesinin anlaşılır olup olmadığını ve bir odak halkasının kullanıcının gözünde görünüp görünmediğini ise çoğu zaman yakalayamazlar; Birleşik Krallık hükümetinin 2017'de yaptığı bir denemede, bilerek kurulmuş 143 engelin 42'sini on aracın hiçbiri bulamadı. Bu yüzden renk erişilebilirliği üç katmanda sınanır: araçlar, insan gözüyle yapılan inceleme ve az gören, yaşlı ya da farklı renk gören gerçek kullanıcılarla yapılan testler.

Aracın gördüğü ve görmediği

Otomatik bir erişilebilirlik aracı sayfanın kodunu ve hesaplanmış stillerini okur ve her öğeyi bir kural listesine karşı sınar. Bir paragrafın metin rengi ile zemin rengi stil sayfasında tanımlıysa, araç UX-06'daki formülle oranı hesaplar ve eşiğin altında kalanları işaretler. Bu iş bir insanın saatler süren işini saniyelere indirir ve her derlemede yeniden yapılabilir.

Aracın sınırı da buradan çıkar: araç, kodda karar verilebilen şeyi görür. Metin bir fotoğrafın ya da bir degradenin üzerindeyse, stil sayfasında tanımlı tek bir zemin rengi yoktur; araç ya ölçemediğini söyler ya da bir yedek renge bakıp yanlış bir sonuç verir. Bir bilginin yalnız renkle verilip verilmediğini anlamak, o rengin ne anlama geldiğini bilmeyi gerektirir. Bir hata cümlesinin «Geçersiz giriş» mi yoksa «Doğum tarihi gün/ay/yıl biçiminde olmalı» mı olduğu, bir dil kararıdır.

Birleşik Krallık hükümetinin dijital hizmetler ekibi bu sınırı ölçmek için bir deney yaptı. Ekip, bilerek erişilebilirlik hatalarıyla doldurulmuş bir web sayfası kurdu ve ona «dünyanın en az erişilebilir web sayfası» adını verdi. Sayfada on dokuz kategoride 143 hata vardı. Sayfa, yaygın olarak kullanılan on ücretsiz araçla tarandı. 143 engelin 42'sini, yani yüzde 29'unu, araçların hiçbiri bulamadı. Bulunamayanlar arasında yalnız renkle tanımlanan bağlantılar da vardı; UX-07'deki alt çizgi sorunu, hiçbir aracın yakalamadığı sorunlardan biriydi. En başarılı araç, yalnız hata ve uyarılar sayıldığında engellerin yüzde 37'sini, manuel inceleme istemleri de sayıldığında en iyi araç yüzde 41'ini buldu; popüler bir tarayıcı aracı ise yüzde 17'de kaldı.

Bu sonuç 2017'deki araçlara aittir ve araçlar o günden beri gelişmiştir. Ama deneyin gösterdiği sınır yapısaldır: bir aracın göremediği şeylerin önemli bir kısmı, kodun değil anlamın içindedir. Ekibin kendi benzetmesi doğrudur: bir yazım denetleyicisi yazım hatalarını bulur, ama bir cümlenin anlaşılır olup olmadığına karar veremez.

İnsan gözüyle inceleme

Aracın bıraktığı boşluğu ilk dolduran, ekibin kendi gözüdür. Manuel inceleme bir kontrol listesiyle yapılır ve her sayfada aynı sorular sorulur.

Renk açısından en verimli sorular şunlardır. Sayfa gri tonlamada okunuyor mu ve renkle verilen her bilginin bir yedeği var mı? Metnin bir fotoğrafın ya da degradenin üzerine düştüğü her yer, en kötü piksele göre sınandı mı? Klavyeyle gezinildiğinde odak halkası her öğede, açık ve koyu yüzeylerde görünüyor mu? Üzerine gelme, basılı ve devre dışı hâller birbirinden ayrılıyor mu? Karanlık temada ve yüksek kontrast kipinde aynı sorular yeniden soruluyor mu?

Görme benzetimleri bu incelemenin güçlü bir yardımcısıdır. Chrome'un geliştirici araçları, bir sayfayı bulanık görme, azaltılmış kontrast, protanopi, döteranopi, tritanopi ve akromatopsi benzetimleriyle görüntülemeye izin verir. Belgeleri, protanopi ve döteranopide yeşil, kırmızı ve sarının, tritanopide yeşil ve mavinin karıştığını söyler.

Benzetimin sınırını bilmek de önemlidir. Bir benzetim, bir modelin çıktısıdır; eksikliğin tamamen bulunduğu uç durumu gösterir. BI-12'nin anlattığı gibi renk görme eksikliklerinin çoğu kısmi ve kişiden kişiye değişkendir. Benzetimde okunan bir ekran, kısmi eksikliği olan birinin de okuyacağı anlamına gelir; ama benzetim, o kişinin ekranı nasıl yaşadığını, nerede zorlandığını ve hangi yolları kendi geliştirdiğini göstermez.

Kullanıcının seçtiği renkler

Bazı kullanıcılar tasarımcının renklerini hiç görmez. İşletim sistemlerinin yüksek kontrast temaları ve kullanıcının kendi seçtiği renk düzenleri, sayfanın renklerinin yerine geçer.

CSS'in renk uyarlama belirtimi bu kipi, metnin okunurluğunu renk kontrastıyla artırmak için tasarlanmış bir erişilebilirlik özelliği olarak tanımlar ve az gören pek çok kişinin, ön plan ile zemin arasında belirli bir kontrast türü olduğunda okumayı daha rahat bulduğunu söyler. Belirtim, kullanıcıların yalnız yüksek kontrast değil, düşük kontrast ya da yalnız renk tonu farkı içeren kendi temalarını da kurabileceğini not eder.

Bu kural, ekiplerin sık düştüğü iki tuzağı ortaya çıkarır. Odak halkasını box-shadow ile çizmek bunlardan biridir: zorunlu renk kipinde gölge yok sayıldığı için halka tamamen kaybolur ve UX-04'teki bütün odak özeni boşa gider. Halkayı outline özelliğiyle çizmek bu kipte de görünür kalır. Öbürü, bir butonun biçimini yalnız bir degrade zeminle ya da gölgeyle vermektir: degrade kaldırılır, kenarlık yoksa buton düz bir metin gibi görünür. Butona saydam bir kenarlık vermek, zorunlu renk kipinde bu kenarlığın kullanıcının renginde görünmesini sağlar. Bu tuzakları bir araç çoğu zaman bulamaz; ekibin sayfayı bu kipte açıp gezmesi gerekir.

Gerçek kullanıcılarla test

Araç ve inceleme, ekibin bildiği soruları sorar. Gerçek kullanıcılarla yapılan test, ekibin bilmediği soruları ortaya çıkarır.

Görme sorunları küçük bir azınlığın sorunu değildir. Dünya Sağlık Örgütü'nün 2019 tarihli görme raporu, dünyada en az 2,2 milyar kişinin yakın ya da uzak görmesinde bir bozukluk bulunduğunu ve bunların en az 1 milyarında bu bozukluğun önlenebilir olduğunu ya da henüz giderilmediğini bildirir.

Renk erişilebilirliği için yapılan bir kullanıcı testinde katılımcılar çeşitlendirilir: renk görme eksikliği olanlar, yakınlaştırma ya da yüksek kontrast kipi kullanan az görenler, ekranı uzun süre ve farklı ışıklarda kullanan yaşlı kullanıcılar. Katılımcılara «bu rengi beğendiniz mi?» diye sorulmaz; bir görev verilir ve nerede duraksadıkları izlenir: bir formu doldurup hatayı düzeltmek, bir grafikten bir değer okumak, bir ayarı açıp kapatmak. Test, kişinin kendi cihazında ve kendi ayarlarıyla yapılırsa, ekibin hiç denemediği bir yakınlaştırma düzeyi ya da renk teması da sürece girer.

Bu testlerin sonucu çoğu zaman bir kontrast oranı değildir. Bir katılımcının bir simgeyi başka bir anlamda okuması, bir bilgiyi hiç görmemesi ya da bir butonun devre dışı olduğunu anlamadan ona tekrar tekrar basması, hiçbir aracın raporunda yer almayan bulgulardır.

Testi iş akışına yerleştirmek

Üç katmanın her biri farklı bir sıklıkla çalışır. Otomatik denetim en ucuz olanıdır ve her kod değişikliğinde, derleme sürecinin bir adımı olarak koşabilir; yeni bir düşük kontrastlı metin ya da etiketsiz bir alan, daha kod birleştirilmeden yakalanır. Manuel inceleme daha pahalıdır; her yeni ekran tasarımında ve her sürüm öncesinde, bir kontrol listesiyle yapılır. Kullanıcı testi en pahalı ve en bilgilendirici olanıdır; büyük bir tasarım değişikliğinden önce, bir renk sistemi ya da tema yeniden kurulurken ve ürünün en kritik akışları için planlanır.

Bu sıralama bir önem sıralaması değildir. Otomatik denetimin bulduğu her sorun, insanların vaktini daha zor sorunlara ayırmasını sağlar; kullanıcı testinin bulduğu her sorun da çoğu zaman bir sonraki kontrol listesine yeni bir madde olarak eklenir. Zamanla ekip, bir kez kullanıcıda gördüğü bir hatayı her sürümde manuel olarak, mümkünse otomatik olarak aramaya başlar.

Örnek — portre üzerindeki başlık

Bir haber sitesinin ana sayfasında, her gün değişen bir portre fotoğrafının üzerine beyaz bir başlık yazılıyor. Ekibin otomatik aracı her derlemede sayfayı tarıyor ve başlığı kontrast açısından geçerli buluyor: stil sayfasında başlığın arkası için, fotoğraf yüklenmezse görünecek #333333 koyu grisi tanımlı ve beyaz bu gri üzerinde rahatça eşiğin üstünde.

Ama başlığın gerçekte üzerine düştüğü şey fotoğraftır ve fotoğraf her gün başka biridir. Hesap farkı gösteriyor: beyaz metin, #8D5524 tonundaki bir yanağın üzerinde yaklaşık 6,1:1, #4A2C1D tonunda 12,6:1 verirken, #C68863 tonunda 3,0:1'e, #F1C7A9 tonunda 1,6:1'e düşüyor. Aynı başlık, koyu tenli birinin portresinde rahatça okunuyor, açık tenli birinin portresinde ise neredeyse kayboluyor; araç iki gün için de aynı «geçti» raporunu veriyor, çünkü fotoğrafa hiç bakmıyor.

Ekip sorunu araçta değil süreçte çözüyor. Başlığın arkasına, fotoğraftan bağımsız olarak metnin eşiği aşmasını sağlayan yarı saydam koyu bir şerit ekleniyor. Manuel inceleme listesine «metin fotoğrafın üzerindeyse, en açık bölgeye göre ölç» maddesi yazılıyor. Yayın öncesi kontrol için, açık, buğday, esmer ve çok koyu tenleri; düz ve karmaşık arka planları içeren bir deneme seti hazırlanıyor ve başlık her birinin üzerinde denetleniyor. Son olarak sayfa zorunlu renk kipinde açılıyor: şerit bir degrade değil düz bir zemin rengi olarak tanımlandığı için bu kipte kaldırılmıyor, kullanıcının seçtiği zemin rengine dönüşüyor ve başlık, kullanıcının metin rengiyle okunur kalıyor.

Sık yapılan yanlış

Özet

1. Otomatik araçlar kodda karar verilebilen sorunları hızlı ve tekrarlanabilir biçimde bulur; fotoğraf ya da degrade üzerindeki metni, yalnız renkle verilen bilgiyi ve metnin anlaşılırlığını çoğu zaman göremez.
2. Manuel inceleme gri tonlama, görme benzetimi, klavye ve zorunlu renk kipiyle yapılır; zorunlu renk kipinde gölgeler ve degradeler kaldırıldığı için odak halkası outline ile, buton sınırı kenarlıkla verilir.
3. Az gören, yaşlı ve farklı renk gören kullanıcılarla yapılan görev temelli testler, hiçbir aracın raporunda olmayan bulguları ortaya çıkarır; fotoğraf üzerindeki metin, geniş bir ten aralığını kapsayan bir portre setiyle en açık bölgeye göre sınanır.

Kendini sına

1. (Kolay) Birleşik Krallık hükümetinin 2017 denemesinde kurulan 143 engelin kaçı hiçbir araç tarafından bulunamadı?
2. (Kolay) Chrome DevTools'un görme eksikliği benzetimleri hangi seçenekleri sunar?
3. (Orta) Otomatik araçlar hangi erişilebilirlik sorunlarını yakalayamaz?
4. (Orta) Zorunlu renk kipinde box-shadow ile çizilmiş bir odak halkasına ne olur ve ne yapılmalıdır?
5. (Zor) Bir görme benzetiminin sonucu neden kullanıcı testinin yerini tutmaz?
6. (Zor) Portre üzerindeki başlık neden otomatik araçtan geçtiği hâlde bazı günler okunmaz ve süreç nasıl düzeltilir?

Cevaplar

1. 42'si, yani yüzde 29'u («Aracın gördüğü ve görmediği»).
2. Bulanık görme, azaltılmış kontrast, protanopi, döteranopi, tritanopi ve akromatopsi («İnsan gözüyle inceleme»).
3. Stil sayfasında tek bir zemin rengi olmayan, fotoğraf ya da degrade üzerindeki metnin gerçek kontrastını; bir bilginin yalnız renkle verilip verilmediğini, örneğin yalnız renkle ayrılan bağlantıları; bir hata cümlesinin anlaşılır olup olmadığını; odak halkasının ve durum farklarının gerçekten görünüp görünmediğini ve zorunlu renk kipinde kaybolan öğeleri çoğu zaman yakalayamazlar. Bunlar kodun değil anlamın ve görüntünün içindedir («Aracın gördüğü ve görmediği», «Kullanıcının seçtiği renkler»).
4. Zorunlu renk kipinde box-shadow yok sayılır ve halka tamamen kaybolur. Halka outline özelliğiyle çizilmelidir; buton sınırları da degrade ya da gölge yerine kenarlıkla verilmelidir («Kullanıcının seçtiği renkler»).
5. Benzetim bir modelin, eksikliğin tamamen bulunduğu uç durumdaki çıktısıdır; kısmi ve kişiden kişiye değişen eksiklikleri, kişinin kendi ayarlarını ve kullandığı yolları, bir simgeyi nasıl yorumladığını göstermez. Benzetim ön elemeyi yapar, görev temelli test ise ekibin bilmediği soruları ortaya çıkarır («İnsan gözüyle inceleme», «Gerçek kullanıcılarla test»).
6. Araç, stil sayfasındaki #333333 yedek zemine bakar; oysa başlık fotoğrafın üzerine düşer. Beyaz metin #4A2C1D tonunda 12,6:1 verirken #F1C7A9 tonunda 1,6:1'e düşer. Başlığın arkasına düz renkli yarı saydam bir şerit eklenir, inceleme listesine «en açık bölgeye göre ölç» maddesi yazılır, farklı tenlerden portrelerle bir deneme seti hazırlanır ve sayfa zorunlu renk kipinde de açılır («Örnek — portre üzerindeki başlık»).

Kaynaklar

• Mehmet Duran, «What we found when we tested tools on the world's least-accessible webpage», GOV.UK Accessibility blog, 24 Şubat 2017.
• Chrome for Developers, «Apply effects», Emulate vision deficiencies bölümü.
• W3C CSS Working Group, «CSS Color Adjustment Module Level 1», Editor's Draft.
• World Health Organization, «World report on vision», 2019.

Sonraki adım

UX-09 renkleri yazmanın yeni araçlarına geçiyor: oklch() ile kurulan bir ton skalasının basamaklarının neden HSL'dekinden daha dengeli göründüğünü, color-mix() ve göreli renk sözdiziminin bir temayı nasıl tek bir değerden türettiğini ve P3 renkleri desteklemeyen tarayıcılar için geri düşüşün, yayından önce desteği kontrol ederek nasıl kurulacağını anlatıyor. UX-10 ise ekranı bir oyun dünyasına açıyor: gri bir sahnede tek bir sarı çubuğun oyuncuyu nasıl yönlendirdiğini, dost ve düşmanın renkle nasıl kodlandığını ve oyunların renk körlüğü kiplerini ele alıyor.