Otomatik erişilebilirlik testi

Bu kursta şu ana kadar dijital erişilebilirliğin bireysel, işletme ve yasal yönleri ile dijital erişilebilirlik uygunluğunun temelleri hakkında bilgi edindiniz. ARIA'yı HTML'ye karşı ne zaman kullanacağınız, renk kontrastını nasıl ölçeceğiniz ve JavaScript'in ne zaman gerekli olduğu gibi kapsayıcı tasarım ve kodlamayla ilgili belirli konuları incelediniz.

Kalan modüllerde ise tasarım ve geliştirme aşamasından erişilebilirlik testine geçiyoruz. Otomatik, manuel ve yardımcı teknoloji test araçları ile tekniklerini içeren üç adımlı bir test süreci paylaşıyoruz. Web sayfasını erişilemez durumdan erişilebilir duruma getirmek için bu test modüllerinin tamamında aynı demoyu kullanacağız.

Otomatik, manuel ve yardımcı teknoloji testlerinin her biri, mümkün olan en erişilebilir ürünü elde etmek için kritik öneme sahiptir. Testlerimizde standart olarak Web İçeriği Erişilebilirlik Yönergeleri (WCAG) 2.1 uygunluk düzeyi A ve AA kullanılır.

Hangi kurallara uyacağınızı ve hangi düzeyleri karşılayacağınızı sektörünüzün, ürün türünüzün, yerel ve ülke yasalarının ve politikalarının ya da genel erişilebilirlik hedeflerinizin belirlediğini unutmayın. Projeniz için belirli bir standart gerekmiyorsa WCAG'nin en son sürümünü uygulamanız önerilir. Erişilebilirlik denetimleri, uygunluk türleri/seviyeleri, WCAG ve POUR hakkında genel bilgi için "Dijital erişilebilirlik nasıl ölçülür?" başlıklı makaleyi inceleyin.

Artık bildiğiniz gibi, engelli kullanıcıları desteklemek söz konusu olduğunda erişilebilirlik uygunluğu her şeyi ifade etmez. Ancak, karşılaştırma yapabileceğiniz bir metrik sağladığı için iyi bir başlangıç noktasıdır. Daha kapsayıcı ürünler geliştirmenize yardımcı olması için uygunluk testine ek olarak aşağıdaki işlemleri yapmanızı öneririz:

• Engelli kullanıcılarla kullanılabilirlik testleri yapın.
• Ekibinizde engelli kişileri işe alın.
• Dijital erişilebilirlik konusunda uzman bir kişiye veya şirkete danışın.

Otomatik testlerle ilgili temel bilgiler

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

Otomatik erişilebilirlik testlerinin avantajları:

• Ürün yaşam döngüsünün farklı aşamalarında testleri hızlıca tekrarlayın.
• Yalnızca birkaç adımda çalıştırabilir ve çok hızlı sonuçlar alabilirsiniz.
• Testleri çalıştırmak veya sonuçları anlamak için erişilebilirlik hakkında çok az bilgiye ihtiyaç duyulur.

Otomatik erişilebilirlik testlerinin dezavantajları:

• Otomatik araçlar, ürününüzdeki tüm erişilebilirlik hatalarını yakalamaz.
• Bildirilen yanlış pozitifler (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şilebilirliğini kontrol etmek için harika bir ilk adımdır 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 otomatik erişilebilirlik test araçlarından biri, 1996'da Center for Applied Special Technology (CAST) tarafından geliştirilmiş ve "The Bobby Report" olarak adlandırılmıştır. Günümüzde, aralarından seçim yapabileceğiniz 100'den fazla otomatik test aracı bulunmaktadır.

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

Hangi otomatik aracı kullanacağınıza karar verirken aşağıdakiler gibi birçok faktörü göz önünde bulundurabilirsiniz:

• Hangi uygunluk standartları ve düzeylerine göre test yapıyorsunuz? Bu, WCAG 2.2, WCAG 2.1, ABD Bölüm 508 veya değiştirilmiş bir erişilebilirlik kuralları 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 aşamasında test ediyorsunuz?
• Aracın kurulumu ve kullanımı ne kadar sürer? Birey, ekip veya şirket için mi?
• Testi kim yapıyor: tasarımcılar, geliştiriciler, KG veya başka biri mi?
• Erişilebilirliğin ne sıklıkta kontrol edilmesini istiyorsunuz? Rapora hangi bilgiler eklenmelidir? Sorunlar doğrudan bir bilet sistemine mi bağlanmalıdır?
• Ortamınızda en iyi sonuçları hangi araçlar veriyor? Ekibiniz için mi?

Ayrıca dikkate alınması gereken birçok ek faktör vardır. Sizin ve ekibiniz için en iyi aracı nasıl seçeceğiniz hakkında daha fazla bilgi edinmek için WAI'nin "Web Erişilebilirliği Değerlendirme Araçlarını Seçme" başlıklı makalesine göz atın.

Demo: Otomatik test

Otomatik erişilebilirlik testi demosunda Chrome'un Lighthouse aracını kullanacağız. Lighthouse, performans, SEO ve erişilebilirlik gibi farklı denetim türleri aracılığıyla web sayfalarının kalitesini artırmak için oluşturulmuş açık kaynaklı, otomatik bir araçtır.

Demomuz, Medical Mysteries Club adlı kurgusal bir kuruluş için oluşturulmuş bir web sitesidir. Bu site, demo için kasıtlı olarak erişilemez hale getirilmiştir. Erişilebilirlik sorunlarının bir kısmı size görünür olabilir. Bir kısmı (ancak tamamı değil) otomatik testimizde tespit edilir.

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ı kullanıyoruz.

2. Adım

CodePen'de bir demo oluşturduk. Bir sonraki testlere devam etmek için hata ayıklama modunda görüntüleyin. Bu önemlidir. Çünkü demo web sayfasını çevreleyen <iframe> kaldırılır. Bu da bazı test araçlarıyla çakışabilir.

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 üzerinde ç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ıktan sonra Lighthouse, test ettiğiniz ürünün ne kadar erişilebilir olduğunu ölçen bir puan gösterir. Lighthouse puanı, tespit edilen sorunların sayısı, sorun türleri ve kullanıcılar üzerindeki etkisiyle hesaplanır.

Lighthouse raporu, puanın yanı sıra tespit ettiği sorunlar hakkında ayrıntılı bilgiler ve bu sorunları düzeltme hakkında daha fazla bilgi edinebileceğiniz kaynak bağlantıları içerir. Rapor, başarılı olan veya geçerli olmayan testlerin yanı sıra manuel olarak kontrol edilecek ek öğelerin listesini de içerir.

5. Adım

Şimdi, tespit edilen her otomatik erişilebilirlik sorunuyla ilgili bir örneği inceleyin ve ilgili stilleri ve işaretlemeyi düzeltin.

1. sorun: ARIA rolleri

İlk sorunda şu ifade yer alıyor: "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 çalışmıyor:

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

Gelin bu 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 bulunuyor. [aria-hidden="true"] öğesi içindeki odaklanabilir alt öğeler, bu etkileşimli öğelerin ekran okuyucu 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>

Gelin bu sorunu çözelim.

Giriş alanına aria-hidden="true" özelliği uygulanmış. Bu özelliği eklediğinizde öğe (ve altındaki tüm öğeler) yardımcı teknolojiden gizlenir.

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

Bu durumda, yardımcı teknoloji kullanan kişilerin form alanına erişip bilgi girebilmesi için bu özelliği girişten kaldırmanız gerekir.

3. sorun: 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>

Gelin bu sorunu çözelim.

1. sorundaki düğme öğesinden yanlış ARIA rolünü kaldırdığınızda "Abone ol" kelimesi erişilebilir düğme adı olur. Bu işlev, semantik HTML düğme öğesine yerleştirilmiştir. Daha karmaşık durumlar için göz önünde bulundurabileceğiniz ek kalıp seçenekleri vardır.

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

4. sorun: Resimlerin 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>

Gelin bu sorunu çözelim.

Logo resmi de bir bağlantı olduğundan, resim modülünden bunun harekete geçirici resim olarak adlandırıldığını ve resmin amacı hakkında alternatif metin bilgileri gerektiğini anlıyorsunuz. Genellikle sayfadaki ilk resim bir logo olduğundan, AT kullanıcılarınızın bunu bildiğini makul bir şekilde varsayabilir ve bu ek bağlamsal bilgiyi 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>

5. sorun: 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>

Gelin bu sorunu çözelim.

Sayfadaki tüm işlem yapılabilir resimler, bağlantının kullanıcıları nereye yönlendirdiğiyle ilgili bilgileri içermelidir. Bu sorunu düzeltmenin bir yolu, örnekteki logo resminde yaptığınız gibi resmin amacını açıklayan alternatif metin eklemektir. Bu yöntem, <img> etiketi kullanan bir resim için çok uygundur ancak <svg> etiketleri bu yöntemi kullanamaz.

<svg> etiketlerinin kullanıldığı 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 veya başka seçenekler ekleyebilirsiniz. Ortamınıza ve kod kısıtlamalarınıza bağlı olarak bir yöntem diğerine göre daha uygun olabilir.

En çok yardımcı teknoloji kapsamına sahip en basit kalıp seçeneğini kullanın. Bu seçenek, <svg> etiketine role="img" eklemeyi ve <title> öğesini içermeyi kapsar.

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

Gelin 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 pikselden küçük) için renk kontrastı 4,5:1 olmalıdır. 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 kontrast oranına sahip olmalıdır.

Sayfa başlığı için, 24 piksel boyutundaki büyük bir metin olduğundan turkuaz renkli metnin 3:1 renk kontrastı şartını karşılaması gerekir. Ancak turkuaz düğmeler 16 piksel kalınlıkta normal boyutlu metin olarak kabul edildiğinden 4,5:1 renk kontrastı şartını karşılamaları gerekir.

Bu durumda, 4.5:1 oranını karşılayacak kadar koyu bir turkuaz rengi bulabilir veya düğme metninin boyutunu 18, 5 piksel kalın olarak artırıp turkuaz rengi değerini biraz değiştirebiliriz. Her iki yöntem de tasarım estetiğine uygun olmalıdır.

Beyaz arka plandaki tüm gri metinler de renk kontrastı açısından başarısız oluyor. Ancak sayfadaki en büyük iki başlık bu durumun dışında kalıyor. Bu metnin, 4.5:1 renk kontrastı şartlarını karşılaması için koyulaştırılması gerekiyor.

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>

Gelin bu sorunu çözelim.

Bu demoda, <ul> etiketi kullanmak yerine sırasız listeyi simüle etmek için bir CSS sınıfı kullandık. Bu kodu yanlış yazdığımızda, bu etikete yerleştirilmiş olan doğal semantik 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 çözüyoruz.

<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ğeri içeriyor. 0'dan büyük bir değer, açık bir gezinme sıralamasını 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>

Gelin bu sorunu çözelim.

Bir web sayfasındaki doğal sekme sırasını bozmak için özel bir neden yoksa tabindex özelliğinde pozitif bir tam sayı kullanılması gerekmez. Doğal sekme sırasını korumak için tabindex değerini 0 olarak değiştirebilir veya özelliği tamamen kaldırabiliriz.

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

6. Adım

Otomatik erişilebilirlik sorunlarını düzelttiğinize göre şimdi yeni bir hata ayıklama modu sayfası açın. Lighthouse erişilebilirlik denetimini tekrar çalıştırın. Puanınız ilk çalıştırmadaki puandan çok daha iyi olmalıdır.

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

Sonraki adım

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