Bu kursta şimdiye kadar bireysel, işletme ve dijital erişilebilirliğin yasal yönleri ve dijital erişilebilirliğin temelleri pek de iyi olmadığını unutmayın. Kapsayıcı tasarımla ilgili belirli konuları keşfettiniz ve Kodlama, ARIA ve HTML'nin ne zaman kullanılacağı, renk kontrastının nasıl ölçüleceği ve ne zaman JavaScript'in gerekli olduğunu gördük.
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. Saat Web sayfasında ilerlemek için bu test modüllerinde aynı demoyu erişilmez.
Her test (otomatik, manuel ve yardımcı teknolojiler), bir ürün ortaya çıktı.
Testlerimiz, Web İçeriği Erişilebilirlik Yönergeleri (WCAG) 2.1'i temel alır. uygunluk düzeyi A ve AA'yı yardımcı olur. Sektörünüz, ürün türünüz, yerel/ülke yasaları ve politikaları veya genel erişilebilirlik hedefleri, hangi yönergelerin 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. Ama iyi bir başlangıç noktası olabilir. test edebileceğiniz bir metrik sağlar. Önerilerimiz: erişilebilirlik uygunluk testi dışındaki ek eylemler (örneğin, engelli kişilerle kullanılabilirlik testleri yapmak, engelli insanları işe almak ya da engelli bireylere ve diğer şirketlere danışmak dijital erişilebilirlik uzmanlığı ile daha kapsayıcı ürünler geliştirmenize yardımcı olun.
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 uygunluğu standartlarına göre erişilebilirlik sorunları.
Otomatik erişilebilirlik testlerinin avantajları:
- Ürün yaşam döngüsünün farklı aşamalarında kolayca tekrarlanabilen testler
- Yalnızca birkaç adımda çalışarak çok hızlı sonuçlar elde edin
- Testleri yapmak veya sonuçları anlamak için erişilebilirlikle ilgili az bilgi gerekir
Otomatik erişilebilirlik testlerinin dezavantajları:
- Otomatik araçlar, ürününüzdeki erişilebilirlik hatalarının tümünü yakalayamaz
- Bildirilen yanlış pozitif (sorunun gerçek WCAG ihlali olmadığı 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. Daha ayrıntılı olarak Otomatikleştirilemeyen öğelerin erişilebilirliğinin nasıl kontrol edileceğine manuel erişilebilirlik testi modülünü kullanabilirsiniz.
Otomatik araç türleri
İlk online otomatik erişilebilirlik test araçlarından biri 1996'da Uygulamalı Özel Teknoloji Merkezi (CAST) tarafından "Bobby Raporu." Günümüzde Seçebileceğiniz 100'den fazla otomatik test aracı başlangıç fiyatıyla!
Otomatik araçların uygulanması, erişilebilirlik tarayıcı uzantılarından masaüstü ve mobil uygulamaları, online kontrol panelleri ve hatta kendi otomatik aracınızı oluşturmak için kullanabileceğiniz açık kaynak API'ler hakkında bilgi edinin.
Hangi otomatik aracı kullanmaya karar vereceğiniz birçok faktöre bağlı olabilir. Örneğin:
- 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 bölümünde test ediyorsunuz?
- Aracı kurmak ve kullanmak ne kadar zaman alır? Şahıslar için ekip mi, şirket mi?
- Testi kim yapıyor: tasarımcılar, geliştiriciler, kalite güvencesi vb.?
- Erişilebilirliğin ne sıklıkta kontrol edilmesini istiyorsunuz? Hangi ayrıntılar belirtilmelidir? dahil edilir mi? Sorunlar doğrudan bilet işlemleri ile bağlantılı mı? bahsedebilir miyiz?
- Ortamınızda en iyi performansı hangi araçlar gösterir? Peki, ekibiniz için mi?
Dikkate alınması gereken birçok başka faktör de var. WAI'ın makalesine göz atın "Selecting Web Accessibility Evaluation Tools" (Web Erişilebilirliği Değerlendirme Araçlarını Seçme) 'nı inceleyin.
Demo: Otomatik test
Otomatik erişilebilirlik testi demosu için Chrome'un Lighthouse. Lighthouse, web sitenizin kalitesini iyileştirmek için geliştirilmiş açık kaynaklı, performans, SEO ve performans gibi farklı denetim türlerine erişilebilirlik.
Demomuz, Tıbbi Gizemler adlı sahte bir kuruluş için oluşturulmuş bir web sitesidir. kulüp. Bu site, demo için kasıtlı olarak erişilemez hale getirildi. Bunlardan bazıları bazı durumlarda (hepsi değil) yakalanabilirsiniz. otomatik testimiz.
1. Adım
Chrome tarayıcınızı kullanarak Lighthouse uzantısı.
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. Daha fazla bilgi:
CodePen'in hata ayıklama modu.
3. Adım
Chrome Geliştirici Araçları'nı açın ve Lighthouse sekmesine gidin. Aşağıdakiler hariç tüm kategori seçeneklerinin işaretini kaldırın: "Erişilebilirlik." Modu varsayılan olarak koruyun ve kullandığınız cihaz türünü seçin uygulayacaksınız.
4. Adım
"Sayfa yüklemeyi analiz et"i tıklayın düğmesini tıklayın ve testlerini yapması için Lighthouse'a zaman tanıyın.
Testler tamamlandıktan sonra Lighthouse, projenizin her bir aşamasını erişilebilir olduğunu anlayabilirsiniz. İlgili içeriği oluşturmak için kullanılan Lighthouse puanı sorunların sayısı, sorun türleri ve uygulamanızın kullanıcıları üzerindeki etkisi tespit etti.
Lighthouse raporunda, skorun ötesinde nelerin olduğuyla ilgili 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. gerekir. Rapor ayrıca geçilen veya geçerli olmayan testleri ve manuel olarak kontrol edilecek ek öğeler listesidir.
5. Adım
Şimdi bu otomatik erişilebilirlik sorunlarına bir örnek verelim. ilgili stilleri ve işaretlemeyi keşfedip düzeltin.
1. Sorun: ARIA rolleri
İlk sorun şu durumu ifade eder: "Çocukların şunları yapmasını gerektiren ARIA [rolü] olan öğeler: [role] [role] bu gerekli alt öğelerin bazılarına veya hiçbirine sahip değil. Bazı ARIA üst rollerinin gerçekleştirilmesi için belirli alt roller içermesi gerekir amaçlanan erişilebilirlik işlevleridir." 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>
"Abone ol" giriş alanının yanındaki düğmenin ARIA rolü yanlış uyguladı. 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>
Giriş alanına bir aria-hidden="true"
özelliği uygulanmıştır. Ekleme
bu özellik, öğeyi (ve altında iç içe yerleştirilmiş her şeyi)
teknikler de vardır.
<input type="email" placeholder="Enter your e-mail address" tabindex="-1" required>
Bu durumda, diğer kullanıcılara izin vermek için bu özelliği girişten kaldırmanız form alanına bilgi girmek ve erişmek için yardımcı teknolojilerden yararlanmak.
Sorun 3: Düğme adı
Düğmelerin erişilebilir adları yok. Bir düğmede erişilebilir ad, ekran okuyucular tarafından “düğme” ve dolayısıyla erişilebilir hale getirebilirsiniz. Düğme adı kuralları hakkında daha fazla bilgi edinin.
<button role="list" type="submit" tabindex="1">Subscribe</button>
Şu öğedeki düğme öğesinden yanlış ARIA rolünü kaldırdığınızda: sorun 1 ise "Abone ol" kelimesi erişilebilir düğme haline gelir dokunun. 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 şunlarla yoksayılabilir:
boş bir alt özelliği olabilir. 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>
Logo resmi aynı zamanda bir bağlantı olduğundan, resim modülünü, üzerinde işlem yapılabilir Bu resim, resmin amacıyla ilgili alternatif metin bilgileri gerektirir. Normalde, sayfadaki ilk resim bir logo olduğu için bu resmin AT kullanıcılarınız bunu bilir ve bu ek öğeleri bağlamsal bilgiler sağlar.
<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. Bağlantı metni (ve resimler için alternatif metin, ayırt edilebilir, benzersiz ve odaklanılabilir olması, reklamınızı kullanıcılara yönelik bir gezinme deneyimi sunmak istiyoruz. Bağlantı metni kuralları hakkında daha fazla bilgi edinin.
<a href="#!"><svg><path>...</path></svg></a>
Sayfadaki işlem yapılabilir görsellerin tümü, projenin neresinde olduklarına dair bilgi içermelidir.
bağlantı, kullanıcıları gönderir. Bu sorunu çözmenin bir yöntemi,
logo resminde yaptığınız gibi, amaca yönelik
yukarıdaki örneğe bakın. 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
bunu kullanıcılardan görsel olarak gizleyebilir, desteklenen bir ARIA ekleyebilir veya diğer seçenekleri kullanabilirsiniz. Şuna bağlı olarak:
açısından bir yöntem tercih edilebilir, mesela bir yöntem yerine
başka bir tane. En basit desen seçeneğini kullanarak en yardımcı ve en kolay
(<svg>
etiketine bir role="img"
ekleniyor ve <svg>
(<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.
Web sayfasında çok sayıda renk kontrastı sorunu tespit edildi. Bu kursta renk ve kontrast modülü normal boyutlu metnin (18 pt / 24 pikselden az) renk kontrastı gereksinimi şunlardır: 4,5:1, büyük boyutlu metin (en az 18 pt / 24 piksel veya 14 pt / 18,5 piksel kalın) ve önemli simgeler 3:1 şartını karşılamalıdır.
Sayfa başlığı için turkuaz renkli metnin 3:1 renk kontrastını karşılaması gerekir 24 piksel boyutundaki büyük metin olduğundan emin olun. Ancak turkuaz düğmeler normal boyutlu metin 16 piksel kalın olarak kabul edilir, bu nedenle 4.5:1 rengi karşılamalıdır. kontrast gereksinimi.
Bu durumda, 4.5:1'i karşılayacak kadar koyu bir turkuaz renk veya düğme metninin boyutunu 18,5 piksel kalın olacak şekilde büyütüp biraz değiştirin. Her iki yöntem de tasarıma uygun olur birlikte çalışır.
Beyaz arka plandaki tüm gri metinler renk kontrastında da başarısız olabilir, yer alır. Toplantı için bu metnin koyulaştırılması gerekir 4.5:1 renk kontrastı gereksinimlerini karşılamanız gerekir.
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 demoda, sıralanmamış listeyi simüle etmek için
(<ul>
etiketi kullanarak). Bu kodu doğru olmayan bir şekilde yazdığımızda,
yerleşik anlamsal HTML özellikleri vardır. Sınıfın yerine 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>
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ırası belirtir. Teknik olarak geçerli olsa da, çoğu zaman yardımcı teknolojilerden yararlanan kullanıcılar için sinir bozucu deneyimler oluşturur. Sekme dizini kuralları hakkında daha fazla bilgi edinin.
<button type="submit" tabindex="1">Subscribe</button>
Web'deki doğal sekme sırasını kesintiye uğratacak belirli bir neden olmadığı sürece
sayfasında, tabindex özelliğinde pozitif bir tam sayı olması gerekmez. 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ırmadan çok daha iyi olacaktı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. Sonra, Şimdi, ayrıntılı kontroller bölümünde açıklandığı gibi, manuel kontrollere manuel erişilebilirlik testi modülünü kullanabilirsiniz.
Öğrendiklerinizi sınayın
Otomatik erişilebilirlik testi hakkındaki bilginizi test edin
Sitenizin erişilebilir olduğundan emin olmak için ne tür testler yapmanız gerekir?
Otomatik testte hangi hatalar yakalanır?