Yılda yalnızca bir kez, tek seferlik manuel incelemeyle kontrol edilen erişilebilirlik neredeyse her zaman hızlı bir şekilde aşınır; herhangi bir küçük kod güncellemesi, halihazırda düzeltilmiş olan bir şeyi bozabilir. Çözüm: Erişilebilirlik testini otomatik bir adım olarak geliştirme sürecinin (CI/CD) içine yerleştirin, böylece sorunlar üretime ulaşmadan önce yakalanır. Bu makalede bunun nasıl yapılacağı açıklanmaktadır.
Kısacası — bu makalenin kapsamı
Tek seferlik kontrol neden yeterli değil?
Güncellemeleri her hafta veya bazen her gün gönderen bir geliştirme ekibi, sürekli uyumluluğu sürdürmek için yıllık erişilebilirlik denetimine güvenemez. Erişilebilirlik düşünülmeden eklenen yeni bir bileşen veya yanlışlıkla kontrastı düşüren bir CSS değişikliği, zaten düzeltilmiş olan erişilebilirliği bozabilir ve bir kullanıcı veya bir şikayet bunu ortaya çıkarana kadar kimse bunu fark etmez. Aynı prensip belgeler için de geçerlidir — kılavuzumuza bakın.yaygın hataları eşleme.
CI/CD kanalındaki hangi otomatik araçlar yakalayabilir?
axe-core, Pa11y veya Lighthouse CI gibi araçlar her çekme isteğinde veya her dağıtımdan önce otomatik olarak çalışabilir; saniyeler içinde renk kontrastı, hatalı veya yinelenen ARIA etiketleri, eksik alt metin, eksik form etiketleri ve hatalı başlık sırası gibi şeyleri kontrol ederler. Denetim başarısız olursa çekme isteğinin birleştirilmesi otomatik olarak engellenir; tıpkı normal kod incelemesi veya başarısız birim testi gibi.
💡 Pratik ipucu
Kod tabanında halihazırda kaç tane sorun bulunduğunu görmek için birkaç hafta boyunca "uyarı modunda" (engellemesiz) başlayın ve yalnızca ilk temizlemeden sonra kontrolü bir dağıtım engelleyiciye dönüştürün; böylece ekip, ilk günde yüzlerce hatayla karşı karşıya kalarak "sıkışıp kalmaz".
Manuel testin hâlâ gerekli olduğu yerler
Belge testinde olduğu gibi, CI/CD kanalındaki otomatik araçlar açık yapısal sorunları yakalar ancak gerçek kullanıcı deneyimini değerlendiremezler: klavyede gezinmenin anlamlı olup olmadığı, ekran okuyucunun sayfada "tutarlı bir hikaye anlatıp anlatmadığı" veya özel bir bileşenin (atlıkarınca veya modal gibi) gerçek dünya kullanımında gerçekten kullanılabilir olup olmadığı. Bu nedenle devam eden otomatik kontrolleri, örneğin üç ayda bir yapılan periyodik manuel denetimle eşleştirmek faydalı olacaktır.
Uygulamada nasıl uygulanır?
- Teknoloji yığınınıza uygun bir test aracı seçin (çoğu JavaScript projesi için axe-core, tarayıcı tabanlı projeler için Lighthouse CI).
- Bunu CI işlem hattınızda bir adım olarak çalıştırın; genellikle GitHub Eylemi, GitLab CI işi veya kullandığınız CI/CD aracındaki eşdeğer bir adım olarak.
- Kontrol bir engelleyici haline gelmeden önce net bir hata eşiği belirleyin (örneğin: eksen çekirdeği başına "kritik" düzeyde sorun yok).
- PDF dosyalarınızı da örtün: Kuruluşunuz belgeleri (faturalar, raporlar) otomatik olarak oluşturuyorsa, yayınlama sürecinin bir parçası olarak bunlar için de otomatik tarama eklemeyi düşünün.
Sürecinize otomatik PDF testini de eklemek ister misiniz?
Aracımız PDF dosyalarını tarar ve her belgeye bir erişilebilirlik puanı verir; bunu CI/CD sürecinizin yanında periyodik bir kontrol olarak çalıştırabilirsiniz.
Sitenizi ücretsiz olarak tarayın ←Taradıktan sonra, bulunan belgeleri şu adresten doğrudan ve ücretsiz olarak erişilebilir hale getirebilirsiniz:AccessiDoc.