Otomatik erişilebilirlik testi

Bu kursta şu ana kadar dijital erişilebilirliğin bireysel, ticari ve yasal yönleri ile dijital erişilebilirlik uygunluğunun temelleri hakkında bilgi edindiniz. ARIA'nın HTML'ye kıyasla ne zaman kullanılacağı, renk kontrastının nasıl ölçüleceği ve JavaScript'in ne zaman gerekli olduğu gibi konuların yanı sıra kapsayıcı tasarım ve kodlamayla ilgili belirli konuları incelediniz.

Kalan modüllerde, tasarım ve geliştirme aşamasından test aşamasına geçiyoruz. göz önünde bulundurun. Üç adımlı bir test süreci kullanacağız. Bu süreçte otomatik, manuel ve yardımcı teknoloji testi araçları ve tekniklerini test etmek için kullanılır. Web sayfasını erişilemez durumdan erişilebilir duruma getirmek için bu test modülleri boyunca aynı demoyu kullanırız.

Otomatik, manuel ve yardımcı teknoloji testlerinin her biri, mümkün olan en erişilebilir ürünü sunmak için çok önemlidir.

Testlerimizde standart olarak Web İçeriği Erişilebilirlik Yönergeleri (WCAG) 2.1 uyumluluk düzeyi A ve AA'yı kullanırız. Sektörünüzün, ürün türünüzün, yerel ve ülkenizin yasalarının ve politikaları veya genel erişilebilirlik hedefleri, takip edip seviye atlatın. İşletmeniz için belirli bir standarda ihtiyaç duymuyorsanız, WCAG’nin en son sürümünü uygulamanız önerilir. "Dijital erişilebilirlik nasıl ölçülür?" konusuna bakın. erişilebilirlik denetimleri, uygunluk türleri/seviyeleri ve WCAG ve AKTAR.

Bildiğiniz gibi erişilebilirlik uygunluğu hikayenin tamamını tespit etmez. engelli bireyleri desteklemeye geldi. Ancak test edebileceğiniz bir metrik sağladığı için iyi bir başlangıç noktasıdır. Erişilebilirlik uygunluğu testinin dışında ek işlemler yapmanızı öneririz. Örneğin, engelli kişilerle kullanılabilirlik testleri yapma, ekibinizde çalışmak üzere engelli kişileri işe alma veya daha kapsayıcı ürünler geliştirmenize yardımcı olması için dijital erişilebilirlik konusunda uzman bir kişiye ya da şirkete danışabilirsiniz.

Otomatik test ile ilgili temel bilgiler

Otomatik erişilebilirlik testi, dijital ürününüzü aşağıdaki amaçlarla tarayan bir yazılım kullanır: Önceden tanımlanmış erişilebilirlik uygunluk standartlarına göre erişilebilirlik sorunları.

Otomatik erişilebilirlik testlerinin avantajları:

• Testleri ürün yaşam döngüsünün farklı aşamalarında tekrarlamak kolaydır.
• Yalnızca birkaç adımda çalıştırılabilir ve çok hızlı sonuçlar verir.
• Testleri çalıştırmak veya sonuçları anlamak için çok fazla erişilebilirlik bilgisine sahip olmanız gerekmez.

Otomatik erişilebilirlik testlerinin dezavantajları:

• Otomatik araçlar, ürününüzdeki erişilebilirlik hatalarının tümünü yakalayamaz
• Yanlış pozitif bildirme (gerçek bir WCAG ihlali olmayan bir sorun bildirilir)
• Farklı ürün türleri ve roller için birden çok araç gerekebilir.

Otomatik test, web sitenizde veya uygulamanızda test yapmanın ancak tüm kontroller otomatikleştirilemez. Otomatikleştirilemeyen öğelerin erişilebilirliğini kontrol etme hakkında daha fazla bilgiyi manuel erişilebilirlik testi modülünde bulabilirsiniz.

Otomatik araç türleri

İlk online otomatik erişilebilirlik test araçlarından biri, 1996 yılında Center for Applied Special Technology (CAST) tarafından "Bobby Report" adıyla geliştirildi. Günümüzde, aralarından seçim yapabileceğiniz 100'den fazla otomatik test aracı bulunuyor.

Otomatik araç uygulama yöntemleri, erişilebilirlik tarayıcı uzantılarından kod temizleyicilere, masaüstü ve mobil uygulamalara, online kontrol panellerine ve hatta kendi otomatik araçlarınızı oluşturmak için kullanabileceğiniz açık kaynak API'lere kadar çeşitlilik gösterir.

Hangi otomatik aracı kullanmaya karar vereceğiniz aşağıdakiler gibi birçok faktöre bağlı olabilir:

• Hangi uygunluk standartları ve düzeylerine göre test yapıyorsunuz? Bu, WCAG 2.1, WCAG 2.0, ABD Bölüm 508 veya erişilebilirlik kurallarının değiştirilmiş bir listesi.
• Ne tür bir dijital ürünü test ediyorsunuz? Bu bir web sitesi veya web olabilir uygulama, yerel mobil uygulama, PDF, kiosk veya başka bir üründen çıkarabilirsiniz.
• Ürününüzü yazılım geliştirme yaşam döngüsünün hangi aşamasında test ediyorsunuz?
• Aracı kurmak ve kullanmak ne kadar zaman alır? Şahıslar için yoksa şirketten biri mi?
• Testi kim yapıyor: tasarımcılar, geliştiriciler, kalite güvencesi mi yoksa başka biri mi?
• Erişilebilirliğin ne sıklıkta kontrol edilmesini istiyorsunuz? Hangi ayrıntılar belirtilmelidir? dahil edilir mi? Sorunlar doğrudan bir destek kaydı sistemine bağlanmalı mı?
• Ortamınızda en iyi performansı hangi araçlar gösterir? Ekibiniz için mi?

Dikkate alınması gereken birçok başka faktör de var. Sizin ve ekibiniz için en iyi aracı nasıl seçeceğiniz hakkında daha fazla bilgi için WAI'ın "Web Erişilebilirlik Değerlendirme Araçları Seçimi" konulu makalesine göz atın.

Demo: Otomatik test

Otomatik erişilebilirlik testi demosu için Chrome'un Lighthouse. Lighthouse, performans, SEO ve erişilebilirlik gibi farklı türde denetimler aracılığıyla web sayfalarının kalitesini iyileştirmek için oluşturulmuş açık kaynaklı, otomatik bir araçtır.

Demomuzda, kurgusal bir kuruluş olan Tıbbi Gizemler Kulübü için oluşturulmuş bir web sitesi yer alıyor. Bu site, demo için kasıtlı olarak erişilemez hale getirilmiştir. Bunlardan bazıları bazı durumlarda (hepsi değil) yakalanabilirsiniz. otomatik testimiz.

1. Adım

Chrome tarayıcınızı kullanarak Lighthouse uzantısını yükleyin.

Lighthouse'u entegre etmenin birçok yolu vardır test iş akışınıza ekleyebilirsiniz. Bu demo için Chrome uzantısını kullanacağız.

2. Adım

CodePen'de bir demo oluşturduk. İşleminize devam etmek için dosyayı hata ayıklama modunda görüntüleyin. test edebilirsiniz. Etiketin etrafındaki <iframe> öğesini kaldırdığı için bu önemlidir demo web sayfası olsun. Bu durum, bazı test araçlarının çalışmasını etkileyebilir.

CodePen'in hata ayıklama modu hakkında daha fazla bilgi edinin.

3. Adım

Chrome Geliştirici Araçları'nı açın ve Lighthouse sekmesine gidin. "Erişilebilirlik" dışındaki tüm kategori seçeneklerini temizleyin. Modu varsayılan olarak bırakın ve testleri çalıştırdığınız cihaz türünü seçin.

4. Adım

Sayfa yükleme etkinliğini analiz et'i tıklayın ve Lighthouse'un testlerini çalıştırması için zaman tanıyın.

Testler tamamlandığında Lighthouse, test ettiğiniz ürünün erişilebilirliğini ölçen bir puan gösterir. Lighthouse puanı, sorunların sayısı, sorun türleri ve tespit edilen sorunların kullanıcılar üzerindeki etkisine göre hesaplanır.

Lighthouse raporunda, skorun ötesinde nelerin olduğuyla ilgili ayrıntılı bilgiler ve sorunları giderme hakkında daha fazla bilgi edinebileceğiniz kaynakların bağlantılarını içerir. oluşturabilirsiniz. Raporda, başarılı olan veya geçerli olmayan testler ve manuel olarak kontrol edilecek ek öğelerin listesi de yer alır.

5. Adım

Şimdi her bir otomatik erişilebilirlik sorununun örneklerini inceleyelim. ilgili stilleri ve işaretlemeyi keşfedip düzeltin.

1. Sorun: ARIA rolleri

İlk sorun şu şekilde belirtiliyor: "ARIA [role] sahibi olup alt öğelerin belirli bir [role] içermesini gerektiren öğelerde bu gerekli alt öğelerin bazıları veya hiçbiri bulunmuyor. Bazı ARIA üst rollerinin amaçlanan erişilebilirlik işlevlerini gerçekleştirebilmek için belirli alt rolleri içermesi gerekir." ARIA rol kuralları hakkında daha fazla bilgi edinin.

Demomuzda, bültene abone ol düğmesi başarısız olur:

<button role="list" type="submit" tabindex="1">Subscribe</button>

Sorunu çözelim.

Giriş alanının yanındaki "abone ol" düğmesine yanlış bir ARIA rolü uygulanmış. Bu durumda, rol tamamen kaldırılabilir.

<button type="submit" tabindex="1">Subscribe</button>

2. sorun: ARIA gizli

"[aria-hidden="true"] öğelerinde odaklanılabilir alt öğeler var. Odaklanabilir [aria-hidden="true"] öğesi içindeki alt öğeler, bu etkileşimli öğelerin, ekran gibi yardımcı teknolojilerin kullanıcılarına sunulmasını engeller okuyucular. aria-hidden kuralları hakkında daha fazla bilgi edinin.

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>

Bu sorunu çözelim.

Giriş alanına bir aria-hidden="true" özelliği uygulanmıştır. Bu özelliği eklemek, öğeyi (ve altındaki her şeyi) yardımcı teknolojiden gizler.

<input type="email" placeholder="Enter your e-mail address" tabindex="-1" required>

Bu durumda, yardımcı teknoloji kullanan kullanıcıların form alanına erişip bilgi girmesine izin vermek için bu özelliği girişten kaldırmanız gerekir.

Sorun 3: Düğme adı

Düğmelerin erişilebilir adları yok. Düğmelerin erişilebilir özellikli adı olmadığında ekran okuyucular bu düğmeyi yalnızca "düğme" olarak okur. Bu da, ekran okuyuculardan yararlanan kullanıcılar için yararlı olmaz.

Düğme adı kuralları hakkında daha fazla bilgi edinin.

<button role="list" type="submit" tabindex="1">Subscribe</button>

Sorunu çözelim.

1. sayfada düğme öğesinden yanlış ARIA rolünü kaldırdığınızda "Abone ol" kelimesi erişilebilir düğme adı olur. Bu işlev, anlamsal HTML düğme öğesinde yerleşik olarak bulunur. Orada daha karmaşık durumlar için göz önünde bulundurulacak ek kalıp seçenekleridir.

<button type="submit" tabindex="1">Subscribe</button>

4. sorun: Resim alt özellikleri

Resim öğelerinde [alt] özellikleri eksik. Bilgilendirme amaçlı öğelerin hedefi, kullanın. Dekoratif öğeler boş bir alt özelliğiyle yok sayılabilir. Resim alternatif metni hakkında daha fazla bilgi kuralları hakkında daha fazla bilgi edinin.

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>

Bu sorunu çözelim.

Logo resmi de bir bağlantı olduğundan, resim modülünde bu resmin "etkilenebilir resim" olarak adlandırıldığını ve resmin amacıyla ilgili alternatif metin bilgilerinin gerekli olduğunu bilirsiniz. Normalde sayfadaki ilk resim bir logodur. Bu nedenle, AT kullanıcılarınızın bunu bildiğini varsayabilirsiniz ve bu ek bağlamsal bilgileri resim açıklamanıza eklememeye karar verebilirsiniz.

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png"
    alt="Go to the home page.">
</a>

Sorun 5: Bağlantı metni

Bağlantıların ayırt edilebilir adları yok. Ayırt edilebilir, benzersiz ve odaklanılabilir bağlantı metni (ve bağlantı olarak kullanıldığında resimler için alternatif metin), ekran okuyucu kullanıcılarına daha iyi bir gezinme deneyimi sunar. Bağlantı metni kuralları hakkında daha fazla bilgi edinin.

<a href="#!"><svg><path>...</path></svg></a>

Bu sorunu çözelim.

Sayfadaki tüm işlem yapılabilir resimler, bağlantının kullanıcıları nereye yönlendirdiğiyle ilgili bilgi içermelidir. Bu sorunu çözmenin bir yöntemi, logo resminde yaptığınız gibi, amaca yönelik örneğine bakalım. Bu, <img> etiketi kullanan bir resim için çok iyi sonuç verir ancak <svg> etiketleri bu yöntemi kullanamaz.

<svg> etiketlerini kullanan sosyal medya simgeleri için farklı alternatif açıklama kalıbı SVG'leri hedefliyorsanız, bilgileri <a> ve <svg> etiketleri arasına ekleyin ve ardından görsel olarak kullanıcılardan gizleyebilir, desteklenen bir ARIA ekleyebilir veya diğer seçenekleri kullanabilirsiniz. Ortamınıza ve kod kısıtlamalarınıza bağlı olarak bir yöntem diğerine tercih edilebilir.

En basit desen seçeneğini ve en yardımcı olanı kullan teknoloji kapsamı, <svg> etiketine bir role="img" ve (<title> öğesi dahil)

<a href="#!">
  <svg role="img">
    <title>Connect on our Twitter page.</title>
    <path>...</path>
  </svg>
</a>

6. Sorun: Renk kontrastı

Arka plan ve ön plan renkleri yeterli kontrast oranına sahip değil. Birçok kullanıcı, düşük kontrastlı metni okumakta zorlanır veya okuyamaz. Renk kontrastı kuralları hakkında daha fazla bilgi edinin.

İki örnek bildirildi.

ziyaret edin.

Bu sorunu çözelim.

Web sayfasında çok sayıda renk kontrastı sorunu tespit edildi. Renk ve kontrast modülünde öğrendiğiniz gibi, normal boyutlu metinler (18 punto/24 piksel'den küçük) için 4,5:1 renk kontrastı koşulu geçerlidir. Büyük boyutlu metinler (en az 18 punto/24 piksel veya 14 punto/18,5 piksel kalın) ve temel simgeler ise 3:1 koşulunu karşılamalıdır.

Sayfa başlığında, 24 piksel boyutunda büyük bir metin olduğu için turkuaz renkli metnin 3:1 renk kontrastı koşulunu karşılaması gerekir. Ancak turkuaz düğmeler 16 piksel kalınlıkta normal boyutlu metin olarak kabul edildiğinden 4,5:1 renk kontrastı koşulunu karşılamalıdır.

Bu durumda, 4,5:1'i karşılayacak kadar koyu bir turkuaz rengi bulabilir veya düğme metninin boyutunu 18,5 piksel kalınlığa çıkarabilir ve turkuaz renk değerini biraz değiştirebiliriz. Her iki yöntem de tasarım estetiğine uygundur.

Beyaz arka plandaki tüm gri metinler renk kontrastında da başarısız olabilir, yer alır. Bu metin, 4,5:1 renk kontrastı koşullarını karşılamak için koyulaştırılmalıdır.

ziyaret edin.

Sorun 7: liste yapısı

Liste öğeleri (<li>), <ul> veya <ol> üst öğelerinde yer almıyor. Ekran okuyucular, liste öğelerinin (<li>) bir üst öğe içinde yer almasını gerektirir <ul> veya <ol> doğru şekilde duyurulacak.

Liste kuralları hakkında daha fazla bilgi edinin.

<div class="ul">
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</div>

Bu sorunu çözelim.

Bu demoda, sıralanmamış listeyi simüle etmek için (<ul> etiketi kullanarak). Bu kodu yanlış yazdığımızda, bu etikete yerleştirilmiş doğal semantik HTML özelliklerini kaldırdık. Sınıfı gerçek bir <ul> etiketine gidip ilgili CSS'yi değiştirdiğinizde bu erişilebilirlik sorununu çözeriz.

<ul>
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</ul>

8. sorun: tabindex

Bazı öğeler 0'dan büyük bir tabindex değerine sahip. 0'dan büyük bir değer açık bir gezinme sırası belirtir. Bu durum teknik olarak geçerli olsa da yardımcı teknolojilerden yararlanan kullanıcıların genellikle sinir bozucu deneyimler yaşamalarına neden olur. tabindex kuralları hakkında daha fazla bilgi edinin.

<button type="submit" tabindex="1">Subscribe</button>

Bu sorunu çözelim.

Bir web sayfasındaki doğal sekme sırasını bozmak için belirli bir neden yoksa tabindex özelliğinde pozitif bir tam sayı bulunmasına gerek yoktur. Alıcı: doğal sekme sırasını koruduğumuzda, sekme dizinini 0 olarak değiştirebiliriz veya özelliği tamamen kaldırın.

<button type="submit">Subscribe</button>

6. Adım

Tüm otomatik erişilebilirlik sorunlarını düzelttiğinize göre hata ayıklama modu sayfasını ziyaret edin. Lighthouse erişilebilirlik denetimini tekrar çalıştırın. Puanınız ilk çalıştırmaya kıyasla çok daha iyi olmalıdır.

Tüm bu otomatik erişilebilirlik güncellemelerinin tamamını yeni bir CodePen.

Sonraki adım

Mükemmel. Şu ana kadar pek çok şey başardınız, ancak henüz bitirmedik. Ardından, manuel erişilebilirlik testi modülünde ayrıntılı olarak açıklandığı gibi manuel kontrollere geçeceğiz.

Öğrendiklerinizi test etme

Otomatik erişilebilirlik testi hakkındaki bilgilerinizi test edin