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ştirmeden erişilebilirlik testine geçiyoruz. Otomatik, manuel ve yardımcı teknoloji testi araçları ve tekniklerini içeren üç adımlı bir test süreci kullanacağız. Web sayfasını erişilemez durumdan erişilebilir duruma getirmek için bu test modüllerinde aynı demoyu kullanacağız.

Her test (otomatik, manuel ve yardımcı teknoloji), mümkün olan en erişilebilir ürüne ulaşmak açısından kritik öneme sahiptir. Testlerimiz, standart olarak Web İçeriği Erişilebilirlik Yönergeleri (WCAG) 2.1 uygunluk düzeyi A ve AA'ya dayanır.

Sektörünüzün, ürün türünüzün, yerel ve ülkenizin yasaları ile politikalarının veya genel erişilebilirlik hedeflerinizin, hangi kurallara ve düzeylere uyulması gerektiğini belirlediğini unutmayın. Projeniz için belirli bir standarda ihtiyacınız yoksa WCAG'nin en son sürümünü uygulamanız önerilir. Erişilebilirlik denetimleri, uygunluk türleri/düzeyleri, WCAG ve POUR hakkında genel bilgi edinmek için "Dijital erişilebilirlik nasıl ölçülür?" başlıklı makaleyi inceleyin.

Engelli kullanıcıları destekleme konusunda erişilebilirlik uygunluğu tek başına yeterli değildir. Ancak, test yapabileceğiniz bir metrik sağladığı için iyi bir başlangıç noktasıdır. Erişilebilirlik uygunluk testi dışında ek işlemler yapmanızı öneririz. Örneğin, engelli kişilerle kullanılabilirlik testleri yapabilir, ekibinizde çalışmaları için engelli kişileri işe alabilir veya daha kapsayıcı ürünler oluşturmanıza yardımcı olması için dijital erişilebilirlik uzmanlığına sahip bir kişiye ya da şirkete danışabilirsiniz.

Otomatik testle ilgili temel bilgiler

Otomatik erişilebilirlik testi, dijital ürününüzü önceden tanımlanmış erişilebilirlik uygunluk standartlarına göre erişilebilirlik sorunları açısından taramak için yazılım kullanır.

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 yapmak veya sonuçları anlamak için erişilebilirlikle ilgili az miktarda bilgi gerekir.

Otomatik erişilebilirlik testlerinin dezavantajları:

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

Otomatik test, web sitenizin veya uygulamanızın erişilebilirlik durumunu kontrol etmek için ideal bir ilk adımdır ancak tüm kontroller otomatikleştirilemez. Manuel erişilebilirlik testi modülünde, otomatikleştirilemeyen öğelerin erişilebilirliğinin nasıl kontrol edileceği konusunda daha ayrıntılı bilgi vereceğiz.

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 arasından seçebileceğiniz 100'den fazla otomatik test aracı vardır.

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 listesini içerebilir.
  • Ne tür bir dijital ürünü test ediyorsunuz? Bu bir web sitesi, web uygulaması, yerel mobil uygulama, PDF, kiosk veya başka bir ürün olabilir.
  • Ürününüzü yazılım geliştirme yaşam döngüsünün hangi bölümünde test ediyorsunuz?
  • Aracı kurmak ve kullanmak ne kadar sürer? Bireysel mi, ekip mi yoksa şirket için 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? Rapora hangi bilgiler eklenmelidir? Sorunlar doğrudan bir destek kaydı sistemine bağlanmalı mı?
  • Ortamınızda en iyi performansı hangi araçlar sağlıyor? Ekibiniz için mi?

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

Demo: Otomatik test

Otomatik erişilebilirlik testi demosu için Chrome'un Lighthouse aracını kullanacağız. 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. Bu erişilememelerin bir kısmını siz görebilirsiniz ancak bazıları (hepsi değil) otomatik testimizde yakalanabilir.

1. Adım

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

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

2. Adım

Tıbbi Gizem Kulübü web sitesi.

CodePen'de bir demo oluşturduk. Sonraki testlere devam etmek için etiketi hata ayıklama modunda görüntüleyin. Bu, demo web sayfasını çevreleyen ve bazı test araçlarını etkileyebilecek <iframe> öğesini kaldırdığından önemlidir.

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

3. Adım

Chrome Geliştirici Araçları'nı açıp 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.

Lighthouse raporu DevTools panelinin açık olduğu Medical Mystery Club web sitesi.

4. Adım

Sayfa yüklemeyi analiz et'i tıklayın ve Lighthouse'a testlerini çalıştırması için zaman verin.

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 raporu, puan dışında tespit ettiği sorunlarla ilgili ayrıntılı bilgiler ve bu sorunları giderme hakkında daha fazla bilgi edinebileceğiniz kaynakların bağlantılarını içerir. Raporda, başarılı olan veya geçerli olmayan testler ve manuel olarak kontrol edilecek ek öğelerin listesi de yer alır.

Medical Mysteries Club web sitesi, Aralık 2022'deki testimizde Lighthouse puanı olarak 62 aldı.

5. Adım

Şimdi, tespit edilen her otomatik erişilebilirlik sorununun bir örneğini inceleyelim ve ilgili stiller ile işaretlemeyi 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 olma düğmesi başarısız oluyor:

<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 odaklanabilir alt öğe bulunuyor. [aria-hidden="true"] öğesi içindeki odaklanılabilir alt öğeler, bu etkileşimli öğelerin ekran okuyucular gibi yardımcı teknolojilerin kullanıcılarına sunulmasını engeller. aria-hidden kuralları hakkında daha fazla bilgi edinin.

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

Giriş alanına aria-hidden="true" özelliği uygulanmıştı. 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. Daha karmaşık durumlar için kullanılabilecek ek kalıp seçenekleri vardır.

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

4. Sorun: Resim alt özellikleri

Resim öğelerinde [alt] özellikleri eksik. Bilgilendirme amaçlı öğelerin hedefi, kısa ve açıklayıcı alternatif metinler olmalıdır. Dekoratif öğeler boş bir alt özelliğiyle yok sayılabilir. Resim alternatif metni kuralları hakkında daha fazla bilgi edinin.

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

Logo resmi aynı zamanda bir bağlantı olduğundan, resim modülünden bunun işlem yapılabilir resim olarak adlandırıldığını ve resmin amacıyla ilgili alternatif metin bilgilerine ihtiyaç duyduğ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>

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>
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 gidermek için bir yöntem, resime amacı hakkında alternatif metin eklemektir (örnekteki logo resminde yaptığınız gibi). Bu yöntem, <img> etiketi kullanan resimler için mükemmel bir şekilde çalışır ancak <svg> etiketleri bu yöntemi kullanamaz.

<svg> etiketleri kullanılan sosyal medya simgeleri için SVG'leri hedefleyen farklı bir alternatif açıklama kalıbı kullanabilir, bilgileri <a> ve <svg> etiketleri arasına ekleyip kullanıcılardan görsel olarak gizleyebilir, desteklenen bir ARIA ekleyebilir veya başka seçenekler kullanabilirsiniz. Ortamınıza ve kod kısıtlamalarınıza bağlı olarak bir yöntem diğerine tercih edilebilir.

En çok yardımcı teknoloji kapsamına sahip en basit desen seçeneğini kullanın. Bu seçenek, <svg> etiketine bir role="img" ekleyip bir <title> öğesi dahil etmektir.

<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.

Tıbbi Gizemler Kulübü'nün onaltılık renk değeri #01aa9d, arka plan onaltılık değeri ise #ffffff. Renk kontrast oranı 2,9:1'dir.
Deniz kızı sendromu metni için Lighthouse puanı.
Denizkızı sendromu metninin onaltılık değeri #7c7c7c, arka planın onaltılık rengi ise #ffffff'dir. Renk kontrast oranı 4,2:1'dir.
Sorunu çözelim.

Web sayfasında çok sayıda renk kontrastı sorunu tespit edildi. Renk ve kontrast modülünde öğrendiğiniz gibi, normal boyutlu metinlerin (18 pt / 24 pikselden küçük) renk kontrastı gereksinimi 4,5:1, büyük boyutlu metinler ise (en az 18 pt / 24 pks veya 18,5 pks / 18,5 pks kalın) ve gerekli simgelerin 3:1 punto gereksinimini karşılaması gerekir.

Sayfa başlığı için turkuaz renkli metnin 24 piksel boyutundaki büyük metin olduğundan 3:1 renk kontrastı gereksinimlerini 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.

Sayfadaki en büyük iki başlık dışında, beyaz arka plandaki tüm gri metinler de renk kontrastı açısından başarısız. Bu metin, 4,5:1 renk kontrastı koşullarını karşılamak için koyulaştırılmalıdır.

Turkuaz sabittir ve artık başarısız olmaz.
Medical Mysteries Club adlı kulübün adı için #008576 renk değeri, arka plan için ise #ffffff değeri verilmiştir. Güncellenen renk kontrast oranı 4,5:1'dir. Tam boyutta görüntülemek için resmi tıklayın.
Gri renk düzeltildi.
Mermaid syndrome için renk değeri #767676 olarak ayarlandı ve arka plan rengi #ffffff olarak kaldı. Renk kontrast oranı 4,5:1'dir.

7. Sorun: Liste yapısı

Liste öğeleri (<li>), <ul> veya <ol> üst öğelerinde yer almıyor. Ekran okuyucuların liste öğelerini (<li>) düzgün bir şekilde okuyabilmesi için liste öğelerinin, üst <ul> veya <ol> öğesinde yer alması gerekir.

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>
Sorunu çözelim.

Bu demoda, <ul> etiketi kullanmak yerine sıralanmamış listeyi simüle etmek için bir CSS sınıfı kullandık. Bu kodu doğru olmayan bir şekilde yazdığımızda, bu etikette yerleşik olarak bulunan kendiliğinden anlamsal HTML özelliklerini kaldırdık. Sınıfı gerçek bir <ul> etiketiyle değiştirip ilgili CSS'yi değiştirerek 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ıralamasını belirtir. Bu durum teknik olarak geçerli olsa da genellikle yardımcı teknolojilerden yararlanan kullanıcıların can sıkıcı deneyimler yaşamasına neden olur. tabindex kuralları hakkında daha fazla bilgi edinin.

<button type="submit" tabindex="1">Subscribe</button>
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. Doğal sekme sırasını korumak için sekme dizinini 0 olarak değiştirebilir veya özelliği tamamen kaldırabiliriz.

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

6. Adım

Tüm otomatik erişilebilirlik sorunlarını düzelttikten sonra yeni bir hata ayıklama modu sayfası açın. Lighthouse erişilebilirlik denetimini tekrar çalıştırın. Puanınız ilk çalıştırmada çok daha yüksek olacaktır.

Başarılı.
Lighthouse puanı artık 100. Bu, tüm Lighthouse sorunlarını giderdiğiniz anlamına geliyor.

Bu otomatik erişilebilirlik güncellemelerinin tümünü yeni bir CodePen'e uyguladık.

Sonraki adım

Mükemmel. Çok şey başardınız ancak henüz işimiz bitmedi. Daha sonra, manuel erişilebilirlik testi modülünde ayrıntılı olarak açıklanan manuel kontrollere geçeceğiz.

Öğrendiklerinizi sınayın

Otomatik erişilebilirlik testi hakkındaki bilgilerinizi test edin

Sitenizin erişilebilir olduğundan emin olmak için ne tür testler yapmalısınız?

Otomatik test
Kullanıcı testi
Manuel test
Yardımcı teknoloji testleri

Otomatik testte hangi hatalar yakalanır?

ARIA hataları
Açıklayıcı form etiketleri
Renk kontrastı sorunları
Kapsayıcı dil
Alternatif metin eksik