Otomatik erişilebilirlik testi

Bu kursta şimdiye kadar dijital erişilebilirliğin bireysel, ticari ve yasal yönleri ve dijital erişilebilirlik uygunluğuyla ilgili temel bilgiler edindiniz. ARIA ve HTML'nin ne zaman kullanılacağı, renk kontrastının nasıl ölçüleceği, JavaScript'in ne zaman gerekli olduğu ve diğer konuların nasıl kullanılacağı gibi kapsayıcı tasarım ve kodlamayla ilgili belirli konuları keşfettiniz.

Kalan modüllerde, erişilebilirlik için tasarım ve geliştirme aşamasından teste geçiş yapıyoruz. Otomatik, manuel ve yardımcı teknoloji test araçlarını ve tekniklerini içeren üç adımlı bir test süreci kullanacağız. Bu test modülleri boyunca, web sayfasını erişilemeyen hale getirmek için aynı demoyu kullanacağız.

Her test (otomatik, manuel ve yardımcı teknolojiler), mümkün olan en erişilebilir ürüne ulaşmak için kritik öneme sahiptir.

Testlerimiz, standartlarımız olarak Web İçeriği Erişilebilirlik Yönergeleri (WCAG) 2.1 uygunluk düzeyi A ve AA'yı temel alır. Sektör, ürün türü, yerel/ülke yasaları ve politikalarınızın ya da genel erişilebilirlik hedeflerinizin hangi yönergelerin uygulanacağını ve hangi düzeylerin karşılanacağını belirlediğini unutmayın. Projeniz için belirli bir standarda ihtiyaç duymuyorsanız WCAG’in en son sürümünü izlemenizi öneririz. Erişilebilirlik denetimleri, uygunluk türleri/seviyeleri, WCAG ve DEVAM hakkında genel bilgi için "Dijital erişilebilirlik nasıl ölçülür?" bölümüne bakın.

Artık bildiğiniz gibi, engelli bireyleri desteklemek söz konusu olduğunda erişilebilirlik uygunluğu, tam anlamıyla değildir. Ancak, test edebileceğiniz bir metrik sağladığı için bu iyi bir başlangıç noktasıdır. Erişilebilirlik uygunluk testinin dışında, daha kapsayıcı ürünler geliştirmenize yardımcı olması için engelli kişilerle kullanılabilirlik testleri yapmak, ekibinizde çalışmaları için engelli kişileri işe almak veya dijital erişilebilirlik uzmanlığı olan bir kişiye ya da şirkete danışmak gibi ek işlemler yapmanızı öneririz.

Otomatik test ile ilgili temel bilgiler

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

Otomatik erişilebilirlik testlerinin avantajları:

• Ürün yaşam döngüsünün farklı aşamalarında, tekrarlanması kolay testler
• Yalnızca birkaç adımda çalıştırıp çok hızlı sonuçlar alabilirsiniz
• Testleri çalıştırmak veya sonuçları anlamak için çok az erişilebilirlik bilgisi gerekir.

Otomatik erişilebilirlik testlerinin dezavantajları:

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

Otomatik test, web sitenizin veya uygulamanızın erişilebilirlik açısından kontrol edilmesi için harika 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ğini daha ayrıntılı bir şekilde inceleyeceğiz.

Otomatik araç türleri

İlk çevrimiçi otomatik erişilebilirlik test araçlarından biri, 1996 yılında "The Bobby Report" adı verilen Uygulamalı Özel Teknoloji Merkezi (CAST) tarafından geliştirilmiştir. Günümüzde seçebileceğiniz 100'den fazla otomatik test aracı var.

Otomatik araç uygulaması, erişilebilirlik tarayıcı uzantılarından kod hata bildirimlerine, 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 farklılık gösterir.

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

• Hangi uygunluk standartlarını ve seviyelerini test ediyorsunuz? Bu, WCAG 2.1, WCAG 2.0, U.S. 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ürüyor? Kişi mi, ekip mi ya da şirket için mi?
• Testi kim yapıyor: tasarımcılar, geliştiriciler, KG vb.?
• Erişilebilirliğin ne sıklıkta kontrol edilmesini istiyorsunuz? Raporda hangi ayrıntılara yer verilmelidir? Sorunlar doğrudan bir destek kaydı sistemine mi bağlı?
• Ortamınızda hangi araçlar en iyi şekilde çalışıyor? Ekibiniz için mi?

Dikkate alınması gereken birçok ek faktör de var. Kendiniz ve ekibiniz için en iyi aracı nasıl seçeceğinizle ilgili daha fazla bilgi edinmek için WAI'nın "Web Accessibility Evaluation Tools" (Web Erişilebilirliği 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'unu kullanacağız. Lighthouse; performans, SEO ve erişilebilirlik gibi farklı denetim türleriyle web sayfalarının kalitesini artırmak için oluşturulmuş açık kaynaklı, otomatik bir araçtır.

Demomuz, tıbbi Gizemler Kulübü adlı uydurma bir kuruluş için oluşturulmuş bir web sitesidir. Bu site, demo için kasıtlı olarak erişilemez hale getirilmiştir. Bu erişilebilirlik özelliklerinin bir kısmını sizin görebilirsiniz, bazıları ise (ancak tümü değil) otomatik testimize yakalanır.

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

CodePen'de bir demo oluşturduk. Sonraki testlere devam etmek için hata ayıklama modunda görüntüleyin. Bu işlem, demo web sayfasını çevreleyen <iframe> öğesini kaldırdığı ve bazı test araçlarının çalışmasını etkileyebileceğinden önemlidir. CodePen'in hata ayıklama modu hakkında daha fazla bilgi

3. Adım

Chrome Geliştirici Araçları'nı açın ve Lighthouse sekmesine gidin. "Erişilebilirlik" dışındaki tüm kategori seçeneklerinin işaretini kaldırın. 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üklemesini analiz et" düğmesini tıklayın ve Lighthouse'a 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ı, sorunların sayısı, sorun türleri ve tespit edilen sorunların kullanıcıları üzerindeki etkisine göre hesaplanır.

Lighthouse raporu puanın yanı sıra, tespit ettiği sorunlar hakkında ayrıntılı bilgiler ve bu sorunların çözümü hakkında daha fazla bilgi edinebileceğiniz kaynakların bağlantılarını içerir. Raporda ayrıca, geçilen veya geçerli olmayan testlerin yanı sıra manuel olarak kontrol edilecek ek öğelerin bir listesi bulunur.

5. Adım

Şimdi, keşfedilen her otomatik erişilebilirlik sorununun bir örneğini inceleyelim ve ilgili stiller ile işaretlemeyi düzeltelim.

1. sorun: ARIA rolleri

İlk sorunda şöyle deniyor: "Çocukların belirli bir [rolü] içermesini gerektiren ARIA [rolü] içeren öğelerde, bu gerekli alt öğelerin bazıları veya hiçbiri eksik. 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 hatalıdır:

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

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 gizlendi

"[aria-hidden="true"] öğelerinde odaklanabilir alt öğeler bulunuyor. Bir [aria-hidden="true"] öğesi içindeki odaklanabilir 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>

Bu sorunu çözelim.

Giriş alanına bir aria-hidden="true" özelliği uygulandı. Bu özelliğin eklenmesi, öğenin (ve altındaki iç içe yerleştirilmiş her şeyin) yardımcı teknolojiden gizlenmesine neden olur.

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

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

3. Sorun: Düğme adı

Düğmelerin erişilebilir adları yok. Bir düğmenin erişilebilir adı olmadığında ekran okuyucular bunu "düğme" olarak okuyacağı için ekran okuyuculardan yararlanan kullanıcılar için kullanılamaz hale gelir. Düğme adı kuralları hakkında daha fazla bilgi edinin.

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

Bu sorunu çözelim.

Hatalı ARIA rolünü 1. sorundaki düğme öğesinden kaldırdığınızda "Abone ol" kelimesi erişilebilir düğme adı olur. Bu işlev, anlamsal HTML düğmesi öğesinde yerleşik olarak bulunur. Daha karmaşık durumlar için göz önünde bulundurulması gereken ek kalıp seçenekleri vardır.

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

4. Sorun: Görsel alternatif ö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ği ile yoksayılabilir. Resim alternatif metin 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 aynı zamanda bir bağlantı olduğu için resim modülünden bunun eyleme dönüştürülebilir resim olarak adlandırıldığını ve resmin amacıyla ilgili alternatif metin bilgileri gerektirdiğini bilirsiniz. Normalde sayfadaki ilk resim bir logodur. Bu nedenle, AT kullanıcılarınızın bunu bileceğini makul bir şekilde 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>

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 metinler), ekran okuyucu kullanıcıları için gezinme deneyimini iyileştirir. Bağlantı metni kuralları hakkında daha fazla bilgi edinin.

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

Bu sorunu çözelim.

Sayfadaki işlem yapılabilir tüm resimler, bağlantının kullanıcıları nereye göndereceği hakkında bilgi içermelidir. Bu sorunu düzeltmenin bir yöntemi, yukarıdaki örnekte verilen logo resminde yaptığınız gibi, amaçla ilgili resme alternatif metin eklemektir. Bu, <img> etiketi kullanan bir resim için idealdir ancak <svg> etiketleri bu yöntemi kullanamaz.

<svg> etiketlerini kullanan sosyal medya simgeleri için SVG'leri hedefleyen farklı bir alternatif açıklama kalıbı kullanabilir, bilgileri <a> ile <svg> etiketleri arasına ekleyip ardından bilgileri kullanıcılardan görsel olarak gizleyebilir, desteklenen bir ARIA veya diğer seçenekler ekleyebilirsiniz. Ortamınıza ve kod kısıtlamalarınıza bağlı olarak, bir yöntem diğerine tercih edilebilir. En yardımcı teknoloji kapsamına sahip en basit kalıp seçeneğini kullanalım. Bu seçenek, <svg> etiketine role="img" ve <title> öğesi ekler.

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

Sorun 6: 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.

Bu sorunu çözelim.

Web sayfasında çok sayıda renk kontrastı sorunu tespit edildi. Renk ve kontrast modülünde de öğrendiğiniz gibi, normal boyutlu metinlerin (18 pt / 24 pikselden küçük) renk kontrastı gereksinimi 4,5:1 iken büyük boyutlu metin (en az 18 pt / 24 piksel veya 14 pt / 18,5 piksel kalın) ve gerekli simgelerin 3:1 olması gerekir.

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

Bu örnekte, 4,5:1 oranına yetecek kadar koyu bir turkuaz rengi bulabilir veya düğme metninin boyutunu 18,5 piksel kalına yükseltip turkuaz renk değerini biraz değiştirebiliriz. Her iki yöntem de tasarım estetiğiyle uyumlu olacaktır.

Sayfadaki en büyük iki başlık hariç, beyaz arka plandaki tüm gri metinlerde renk kontrastı söz konusu değildir. Bu metin, 4.5:1 renk kontrastı gerekliliklerini karşılamak için koyulaştırılmalıdır.

Sorun 7 - liste yapısı

Liste öğeleri (<li>), <ul> veya <ol> üst öğelerinde yer almıyor. Ekran okuyucularda liste öğelerinin (<li>) düzgün bir şekilde duyurulabilmesi için <ul> veya <ol> bir üst öğede 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>

Bu sorunu çözelim.

Bu demoda, sıralanmamış listeyi simüle etmek için <ul> etiketi yerine bir CSS sınıfı kullandık. Bu kodu hatalı şekilde yazdığımızda, bu etikete yerleşik olarak gelen anlamsal HTML özelliklerini kaldırdık. Sınıfı gerçek bir <ul> etiketiyle ve ilgili CSS'de 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>

Sorun 8 - 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 için genellikle sinir bozucu deneyimlere yol açar. Sekme dizini kuralları hakkında daha fazla bilgi edinin.

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

Bu sorunu çözelim.

Bir web sayfasındaki doğal sekme oluşturma sırasını bozmak için belirli bir neden olmadığı sürece, tabindex özelliğinde pozitif bir tam sayı bulunması gerekmez. Doğal sekme düzenini korumak için sekme dizinini 0 olarak değiştirebilir veya özelliği tamamen kaldırabiliriz.

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

6. Adım

Artık otomatik erişilebilirlik sorunlarının tümünü giderdiğinize göre yeni bir hata ayıklama modu sayfası açın. Lighthouse erişilebilirlik denetimini tekrar çalıştırın. Puanınız ilk çalıştırmadan çok daha iyi olacaktır.

Tüm bu otomatik erişilebilirlik güncellemelerini yeni bir CodePen'e uyguladık.

Sonraki adım

Mükemmel. Şimdiye kadar pek çok şey başardık, ancak henüz işimiz bitmedi. Ardından, 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 bilginizi test edin