Otomatik erişilebilirlik testleri neden sorunlarınızın yarısını kaçırır

Otomatik erişilebilirlik testleri hakkında rahatsız edici gerçek

Otomatik erişilebilirlik testi, bir web ekibinin edinebileceği en iyi alışkanlıklardan biridir. Eksik form etiketlerini, düşük kontrastlı metinleri, geçersiz ARIA kullanımını, yinelenen ID’leri, boş düğmeleri ve asla canlı ortama ulaşmaması gereken diğer kusurları yakalar.

Aynı zamanda sık sık yanlış anlaşılır.

Başarılı bir otomatik erişilebilirlik raporu, bir sayfanın erişilebilir olduğu anlamına gelmez. Aracın, tespit etmeyi bildiği sorun alt kümesini bulamadığı anlamına gelir. Bu alt küme değerlidir, ancak sınırlıdır. Birçok erişilebilirlik hatası anlam, sıra, niyet, bağlam ve insan etkileşimine bağlıdır. Yazılım işaretlemeyi inceleyebilir. Ancak deneyimin ekran okuyucu, klavye, büyütme, sesle kontrol, altyazılar veya bilişsel destek kullanan bir kişi için işe yarayıp yaramadığını güvenilir biçimde anlayamaz.

Bu nedenle otomatik testlerin sorunlarınızın yaklaşık yarısını kaçırdığı iddiası alaycı değildir. Hatta cömerttir. Bazı sorun kategorileri yüksek ölçüde otomatikleştirilebilir. Diğerleri ise neredeyse hiç otomatikleştirilemez.

Pratik yanıt otomatik araçları terk etmek değildir. Onları doğru yere koymaktır: erken, sık ve daha geniş bir test iş akışının parçası olarak.

Otomatik testlerin iyi olduğu alanlar

Otomatik araçlar deterministik hataları bulmada mükemmeldir. Bir kural makine tarafından okunabilir bir koşul olarak ifade edilebiliyorsa, bir tarayıcı bunu genellikle hızlı ve tutarlı biçimde kontrol edebilir.

Yaygın örnekler şunlardır:

• Eksik alt özniteliklerine sahip görseller
• İlişkili etiketleri olmayan form girişleri
• Erişilebilir adı olmayan düğmeler
• Kontrast eşiklerini karşılamayan metinler
• Geçersiz ARIA öznitelikleri veya rolleri
• Şüpheli biçimde atlayan başlık seviyeleri
• Eksik veya yinelenmiş landmark’lar
• Boş erişilebilir ada sahip bağlantılar
• Temel yapısı olmayan tablolar

Bu kontrolleri otomatikleştirmeye değer çünkü insanlar tekrarlı denetimde iyi değildir. Bir araç bunları milisaniyeler içinde yakalayabiliyorsa, hiç kimse her sayfayı eksik etiketler için elle taramak zorunda kalmamalıdır.

Otomatik kontroller ayrıca mühendislik iş akışlarında erişilebilirliği tartışmayı kolaylaştırır. CI içinde başarısız olan bir test somuttur. Bir pull request içindeki uyarı zamanındadır. Şablonlar genelinde görülen bir eğilim çizgisi, ekibe iyileştirecek bir şey verir.

Sorun, ekiplerin bu kontrolleri temel hijyenin kanıtı yerine erişilebilirliğin kanıtı olarak görmeye başladığında ortaya çıkar.

Otomasyonun yetersiz kaldığı yerler

Erişilebilirlik yalnızca kodun bir özelliği değildir. Kullanımın bir özelliğidir.

Bir araç size bir görselin alt metni olup olmadığını söyleyebilir. Genellikle bu alt metnin yararlı olup olmadığını söyleyemez. Bir ürün görseli, ürün sayfasında ayrıntılı bir açıklamaya ihtiyaç duyabilir; dekoratif bir hero alanında hiç açıklamaya ihtiyaç duymayabilir; bir yardım makalesinde ise tamamen farklı bir açıklama gerektirebilir. Doğru yanıt bağlama bağlıdır. Bu yüzden ekiplerin yalnızca bir linter kuralına değil, görsel alt metnine pragmatik bir yaklaşım gibi editoryal rehberliğe de ihtiyacı vardır.

Aynı sorun her yerde karşımıza çıkar.

Bir tarayıcı her düğmenin erişilebilir bir adı olduğunu doğrulayabilir. Ancak adın anlamlı olup olmadığını her zaman söyleyemez. Submit adlı beş düğmesi olan bir sayfa temel bir kuralı geçebilir ve yine de ekran okuyucu kullanıcıları için çok kötü bir deneyim sunabilir. Bir modal doğru ARIA özniteliklerine sahip olabilir, ancak odağı yanlış biçimde hapsedebilir. Özel bir açılır menü statik işaretlemede uyumlu görünebilir ve biri onu klavyeyle kullanmaya çalıştığı anda başarısız olabilir.

Otomasyon şu tür sorularda zorlanır:

• Odak sırası görsel ve mantıksal sırayla eşleşiyor mu?
• Her görev yalnızca klavyeyle tamamlanabiliyor mu?
• Hata mesajları belirli, zamanında ve alanlarla ilişkilendirilmiş mi?
• Metin yeniden boyutlandırıldığında veya yakınlaştırıldığında sayfa hâlâ çalışıyor mu?
• Okuma sırası yardımcı teknolojiler için anlamlı mı?
• Talimatlar renge veya konuma dayanmadan anlaşılabiliyor mu?
• Altyazılar, transkriptler ve etiketler içeriği gerçekten iletiyor mu?
• Bir bileşen durumlar arasında öngörülebilir davranıyor mu?

Bunlar uç örnekler değildir. Erişilebilirliğin merkezindedirler.

Yüksek puanın sahte rahatlığı

Erişilebilirlik puanları baştan çıkarıcıdır çünkü karmaşık bir konuyu tek bir sayıya indirger. Bir pano 98 der. Bir rapor yeşil onay işaretleri gösterir. Yayın daha güvenli hissettirir.

Ama puan yalnızca aracın ölçtüğü şeyi ölçer.

Bu, performans testine benzer. Bir Lighthouse raporu önemli sorunları ortaya çıkarabilir, ancak orta seviye bir telefonda yavaş bir ödeme akışında zorlanan gerçek bir kullanıcıyı izlemekle aynı şey değildir. Ekibiniz zaten performans denetimleri kullanıyorsa, aynı zihniyet burada da geçerlidir: raporu dikkatle okuyun, ardından gerçek kullanıcıları etkileyen bulgulara öncelik verin. Bu ayrımı paniklemeden Lighthouse raporu nasıl okunur yazısında ele aldık.

Erişilebilirlik raporları da aynı ölçülülüğü gerektirir. Temiz bir otomatik tarama başlangıç noktasıdır. Sertifika değildir.

Risk, özellikle ekipler taramaları yalnızca statik sayfalara karşı çalıştırdığında yüksektir. Modern arayüzler durum sahibidir: menüler açılır, çekmeceler kayar, toast bildirimleri görünür, doğrulama mesajları güncellenir, sekmeler panelleri değiştirir, filtreler içeriği yeniden yazar ve kimlik doğrulama her şeyi değiştirir. Ciddi erişilebilirlik kusurlarının çoğu bu etkileşimlerin içinde yaşar.

Tarayıcınız yalnızca ilk DOM’u görüyorsa, ürünü kaçırıyordur.

En sık kaçırılan kategoriler

1. Klavye ve odak davranışı

Klavye erişimi, otomasyonun neden yetersiz olduğuna dair en açık örneklerden biridir.

Bir araç bir öğenin odaklanabilir olup olmadığını tespit edebilir. Pozitif tabindex değerlerini veya bariz odak tuzaklarını yakalayabilir. Ancak sekme sırasının tutarlı hissedip hissettirmediğini, bir eylemden sonra odağın doğru yere gidip gitmediğini veya kapatılan bir bileşenin odağı tetikleyiciye geri verip vermediğini güvenilir biçimde değerlendiremez.

Gerçek iş akışı içinde Tab, Shift+Tab, Enter, Space, Escape ve ok tuşlarına basacak bir insana ihtiyacınız vardır.

Bu özellikle özel kontroller için önemlidir. Yerel HTML öğeleri yılların erişilebilirlik davranışını ücretsiz olarak taşır. Düğmeleri, select’leri, onay kutularını, menüleri ve dialog’ları div’lerle yeniden inşa etmek, ekibinizin artık bu davranışın sahibi olduğu anlamına gelir. Etkileşimli bileşenleri inceliyorsanız erişilebilir web düğmeleri için kısa bir kontrol listesi ile başlayın ve aynı disiplini her özel kontrole genişletin.

2. Anlamlı adlar ve açıklamalar

Otomatik araçlar yokluğu tespit edebilir. Kaliteyi tespit etmede ise çok daha zayıftırlar.

Read more adlı bir bağlantının teknik olarak erişilebilir bir adı olabilir. OK etiketli bir düğme geçerli olabilir. Bir form ipucu mevcut olabilir. Peki bağlam içinde anlamlılar mı? Çoğu zaman hayır.

Erişilebilir adlar kullanıcılara ne olacağını veya öğenin neyi temsil ettiğini söylemelidir. Bu muhakeme gerektirir. Ayrıca yalnızca kodla değil, arayüzle test etmeyi gerektirir.

3. Hata yönetimi

Formlar, tarayıcıların yalnızca kısmen yakalayabildiği erişilebilirlik hatalarıyla doludur.

Bir araç etiketsiz bir alanı işaretleyebilir. Ancak doğrulama mesajının çok geç göründüğünü, çok hızlı kaybolduğunu, ekran okuyuculara duyurulmadığını veya Password must be at least 12 characters demesi gerekirken Invalid input dediğini yakalayamayabilir.

İyi hata yönetimi etkileşim tasarımıdır. Elle test ve ideal olarak kullanıcı testi gerektirir.

4. Görsel uyarlama

WCAG; metni yeniden boyutlandırma, reflow, kontrast, aralıklar ve tek bir duyusal ipucuna dayanmama ile ilgili gereksinimler içerir. Bunların bir kısmı otomatik olarak kontrol edilebilir, ancak asıl soru değişen koşullar altında arayüzün kullanılabilir kalıp kalmadığıdır.

%200 yakınlaştırmayı deneyin. Tarayıcı metin yeniden boyutlandırmasını deneyin. Yüksek kontrast veya zorunlu renkler modunu deneyin. Dar viewport genişliklerini deneyin. Azaltılmış hareketi deneyin. Varsayılan ayarlarda cilalı görünen birçok site, kullanıcılar tercihlerini uyguladığında hızla bozulur.

5. İçerik açıklığı

Hiçbir otomatik erişilebilirlik aracı içeriğin anlaşılır olup olmadığını tam olarak değerlendiremez.

Eksik başlıkları veya belirsiz bağlantı metinlerini işaretleyebilir. Ancak sayfanın bir süreci açıkça açıklayıp açıklamadığını, etiketlerin kullanıcı beklentileriyle eşleşip eşleşmediğini veya yoğun metnin kaçınılabilir bilişsel yük yaratıp yaratmadığını bilemez.

Erişilebilirlik yalnızca yardımcı teknoloji uyumluluğu değildir. Aynı zamanda stres altındaki, yabancı bir dil kullanan, dikkat kısıtlarıyla uğraşan veya karmaşık görevlerde yol bulan insanlar için sürtünmeyi azaltmaktır.

Daha iyi bir test iş akışı

Dengeli bir erişilebilirlik iş akışının katmanları vardır.

Otomatik kontrolleri sürekli çalıştırın

Otomatik testleri geliştirme sırasında, pull request’lerde, bileşen önizlemelerinde ve CI’da kullanın. Sıkıcı, hızlı ve pazarlığa kapalı olmalıdırlar. Yeni eksik etiketler ve geçersiz ARIA, keşfedilmek için üç aylık bir denetim gerektirmemelidir.

Bu hataları linting hataları gibi ele alın. Amaç kahramanlık değil; gerilemeyi önlemektir.

Elle klavye testi ekleyin

Anlamlı her kullanıcı akışı için fare olmadan test yapın. Buna gezinme, arama, hesap oluşturma, ödeme, filtreleme, modal’lar, menüler ve form gönderimi dahildir.

En azından şunları doğrulayın:

• Her etkileşimli öğeye erişilebiliyor
• Odak her zaman görünür
• Odak sırası mantıklı
• Beklenen tuşlar çalışıyor
• Escape kapatılabilir overlay’leri kapatıyor
• Bileşenleri açıp kapattıktan sonra odak yönetiliyor
• Klavye tuzağı yok

Bu tek alışkanlık, otomatik taramaların kaçırdığı geniş bir sorun sınıfını yakalar.

En az bir ekran okuyucuyla test edin

Yararlı şeyler öğrenmek için uzman bir ekran okuyucu kullanıcısı olmanız gerekmez. Ancak alçakgönüllülüğe ihtiyacınız vardır. Ekran okuyucu testinin bir öğrenme eğrisi vardır ve yeni başlayanlar sorunları yanlış teşhis edebilir.

Yine de VoiceOver, NVDA veya JAWS ile temel testler; bozuk adları, kafa karıştırıcı okuma sırasını, duyurulmayan güncellemeleri ve bir tarayıcının yakalayamayabileceği landmark sorunlarını ortaya çıkarabilir.

Bunu semantik HTML ile eşleştirin. Ne kadar çok yerel öğe kullanırsanız, erişilebilirliğiniz o kadar az kırılgan olur.

İçeriği ve durumları gözden geçirin

Boş durumları, yükleme durumlarını, hata durumlarını, devre dışı durumları, başarı mesajlarını ve izin hatalarını kontrol edin. Erişilebilirlik hataları çoğu zaman mutlu yolun dışında saklanır.

Ayrıca gerçek kelimeleri de gözden geçirin. Etiketler, başlıklar, talimatlar ve hata mesajları arayüzün parçasıdır.

Risk yüksek olduğunda engelli kullanıcıları dahil edin

Kritik akışlar için elle uzman incelemesi yeterli değildir. Engelli katılımcılarla yapılan kullanıcı testleri, ekiplerin öngöremediği sorunları bulur. Bu özellikle kamu hizmetleri, sağlık, finans, eğitim ve dışlamanın ciddi sonuçlara yol açtığı her akış için önemlidir.

Otomatik test ölçeklenir. İnsan testi anlar.

Otomatik sonuçlar sorumlu biçimde nasıl yorumlanır

Geçtik mi diye sormayın.

Daha iyi sorular sorun:

• Bu araç hangi sorun kategorilerini tespit edebilir?
• Hangi şablonları ve durumları taradı?
• Etkileşimlerden sonra mı çalıştı, yoksa yalnızca ilk yüklemede mi?
• İhlaller kök nedene göre mi gruplandı, yoksa tekrar tekrar mı sayıldı?
• Hangi hatalar kullanıcıların görevleri tamamlamasını engelliyor?
• Neler hâlâ elle inceleme gerektiriyor?

Bu çerçeve konuşmayı değiştirir. Otomatik araçlar otorite değil, kanıt haline gelir.

Ayrıca ekiplerin gereksiz işten kaçınmasına yardımcı olur. Tek bir bileşeni düzeltmek yüzlerce yinelenen ihlali ortadan kaldırabilir. Buna karşılık, yalnızca bir raporlanmış sorunu olan bir sayfa yine de ciddi bir klavye tuzağı içerebilir. Sayılar etki değildir.

Pratik standart: bariz olanı otomatikleştirin, deneyimi elle test edin

En iyi erişilebilirlik ekipleri araç karşıtı değildir. Hayal karşıtıdır.

Makinelerin güvenilir biçimde tespit edebildiği şeyleri otomatikleştirirler. Davranışa ve anlama bağlı olan şeyleri elle test ederler. WCAG gibi standartları, ürünü kullanmanın yerine değil, ortak bir temel olarak kullanırlar.

Mevcut süreciniz yalnızca yayından önce yapılan otomatik bir taramaysa, şu sırayla iyileştirin:

1. Otomatik kontrolleri geliştirme sürecinde daha erken ekleyin.
2. Çekirdek akışları elle klavyeyle test edin.
3. Adları, etiketleri, hataları ve talimatları gözden geçirin.
4. Yaygın bileşenleri bir ekran okuyucuyla test edin.
5. Yüksek riskli yolculuklar için uzman ve kullanıcı testini dahil edin.

Bu mükemmel bir süreç değildir. Gerçekçi bir süreçtir. Ve yeşil bir erişilebilirlik puanının bulabileceğinden çok daha fazlasını bulacaktır.