Manuel erişilebilirlik testi

Manuel test ile ilgili temel bilgiler

Manuel erişilebilirlik testi, otomatik araçların bulamayacağı sorunları bulmak için klavye, görsel ve bilişsel testler, araçlar ve tekniklerden yararlanır. Otomatik araçlar, WCAG'de tanımlanan tüm başarı kriterlerini kapsamadığından, otomatik erişilebilirlik testleri yapıp ardından testi durdurmanız hayati olur.

Teknoloji geliştikçe yalnızca otomatik araçlarla daha fazla test gerçekleştirilebilir. Ancak günümüzde geçerli tüm WCAG kontrol noktalarını kapsaması için test protokollerinize hem manuel hem de yardımcı teknoloji denetimlerinin eklenmesi gerekmektedir.

Manuel erişilebilirlik testlerinin avantajları:

  • Kullanımı kolay ve hızlı
  • Tek başına otomatik testlere kıyasla daha yüksek oranda sorun yakalamak
  • Başarı için çok az araç ve uzmanlık gerekir

Manuel erişilebilirlik testlerinin dezavantajları:

  • Otomatik testlerden daha karmaşık ve zaman alır
  • Geniş ölçekte tekrar etmesi zor olabilir
  • Test çalıştırmak ve sonuçları yorumlamak için daha fazla erişilebilirlik uzmanlığı gerekir

Şu anda otomatik bir araç tarafından algılanabilen ve algılanamayan erişilebilirlik öğelerini ve ayrıntılarını karşılaştıralım.

Otomatikleştirilebilir. Otomatik hale getirilemiyor
Düz renkli arka planlar üzerinde metin renk kontrastı Gradyan/görüntülerdeki metnin renk kontrastı
Resim alternatif metni mevcut Resim alternatif metni doğru ve düzgün şekilde atanmış
Başlıklar, listeler ve önemli noktalar mevcut Başlıklar, listeler ve önemli noktalar doğru şekilde işaretlenmiş ve tüm öğeler dikkate alınmıştır
ARIA mevcut ARIA uygun şekilde kullanılıyor ve doğru öğelere uygulanıyor
Klavyeye odaklanılabilen öğeleri tanımlama Klavye odağı eksik, odaklama sırası mantıklı ve odak göstergesi görünür durumda olan öğeler
iFrame başlığı algılama iFrame kullanıyorsanız odak sırası mantıklıdır ve odak göstergesi görünür olduğunda
Video öğesi mevcut Video öğesinde uygun alternatif medya var (altyazılar ve transkriptler gibi)


Manuel test türleri

Dijital erişilebilirlik için web sayfanıza veya uygulamanıza bakarken göz önünde bulundurmanız gereken birçok manuel araç ve teknik bulunmaktadır. Manuel testte en çok odaklanılan üç alan klavye işlevselliği, görsel odaklı yorumlar ve genel içerik kontrolleridir.

Bu modülde bu konuların her birini genel hatlarıyla ele alacağız. Ancak aşağıdaki testler, yapabileceğiniz veya çalıştırmanız gereken tüm manuel testlerin kapsamlı bir listesi değildir. Saygın bir kaynaktan manuel erişilebilirlik kontrol listesi ile başlamanızı ve belirli dijital ürün ve ekip ihtiyaçlarınız için kendi odaklanmış manuel test kontrol listenizi geliştirmenizi öneririz.

Klavye kontrolleri

Tüm dijital erişilebilirlik sorunlarının yaklaşık% 25'inin klavye desteği eksikliğinden kaynaklandığı tahmin edilmektedir. Klavye odağı modülünde de öğrendiğimiz gibi, bu durum yalnızca gören klavye kullanıcıları, az gören/kör ekran okuyucu kullanıcıları ve içeriğin klavyeden erişilebilir olmasına dayanan teknolojiyi kullanan ses tanıma yazılımı kullanan kişiler de dahil olmak üzere her tür kullanıcıyı etkiler.

Klavye testleri aşağıdaki gibi soruları yanıtlar:

  • Web sayfasının veya özelliğin çalışması için fare gerekiyor mu?
  • Sekme sıralaması mantıklı ve sezgisel mi?
  • Klavye odak göstergesi her zaman görünür mü?
  • Odağı yakalamaması gereken bir öğede takılabilir misiniz?
  • Odağı yakalaması gereken bir öğenin arkasında veya çevresinde gezinebilir misiniz?
  • Odaklanılan bir öğeyi kapatırken odak göstergesi mantıksal bir noktaya döndü mü?

Klavye işlevselliğinin etkisi çok büyük olsa da, test prosedürü oldukça basittir. Tek yapmanız gereken farenizi kenara ayırmak veya küçük bir JavaScript paketi yükleyip yalnızca klavyenizi kullanarak web sitenizi test etmektir. Klavye testi için aşağıdaki komutlar gereklidir.

Anahtar Sonuç
Sekme Bir etkin öğeyi diğerine taşır
ÜstKrktr + Sekme Bir etkin öğeyi geriye taşır
Oklar İlgili kontroller arasında geçiş yapın
Boşluk Eyaletler arasında geçiş yapar ve sayfayı aşağı taşır
ÜstKrktr + Boşluk Tuşu Sayfayı yukarı taşır
Enter Belirli kontrolleri tetikler
Escape Dinamik olarak görüntülenen nesneleri kapatır

Görsel kontroller

Görsel kontroller, sayfanın görsel öğelerine odaklanır ve web sitesini veya uygulamayı erişilebilirlik açısından incelemek için ekran büyütme veya tarayıcı yakınlaştırma gibi araçlardan yararlanır.

Görsel kontrollerden şu bilgiler edinebilirsiniz:

  • Bir renk geçişinin veya resmin üzerindeki metin gibi otomatik bir aracın belirleyemediği renk kontrastı sorunları var mı?
  • Başlıklar, listeler ve diğer yapısal öğelere benzeyen ancak bu şekilde kodlanmamış öğeler var mı?
  • Gezinme bağlantıları ve form girişleri web sitesi veya uygulama genelinde tutarlı mı?
  • Önerileri aşan herhangi bir yanıp sönme, yanıp sönme veya animasyon var mı?
  • İçerikteki boşluklar uygun mu? Harfler, kelimeler, satırlar ve paragraflar için mi?
  • Ekran büyüteci veya tarayıcı yakınlaştırması kullanarak tüm içeriği görebiliyor musunuz?

İçerik kontrolleri

Düzenler, hareket ve renklere odaklanan görsel testlerin aksine içerik kontrolleri sayfadaki kelimelere odaklanır. Kopyanın kendisine bakmakla kalmayıp başkaları için anlamlı olduğundan emin olmak için bağlamı da gözden geçirmelisiniz.

İçerik kontrolleri, aşağıdaki gibi soruların yanıtlarını içerir:

  • Sayfa başlıkları, başlıklar ve form etiketleri anlaşılır ve açıklayıcı mı?
  • Görsel alternatifleri kısa ve öz, doğru ve kullanışlı mı?
  • Anlamı veya bilgiyi aktarmanın tek yolu renk olarak mı kullanılıyor?
  • Bağlantılar açıklayıcı mı yoksa “daha fazla bilgi edinin” ya da “burayı tıklayın” gibi genel metinler mi kullanıyorsunuz?
  • Sayfanın dilinde herhangi bir değişiklik var mı?
  • Basit bir dil mi kullanılıyor ve ilk referansta tüm kısaltmalar yazılıyor mu?

Bazı içerik kontrolleri kısmen otomatik hale getirilebilir. Örneğin, "Burayı tıklayın" ifadesini kontrol eden ve değişiklik yapmanızı öneren bir JavaScript lint aracı yazabilirsiniz. Ancak bu özel çözümlerde, kopyayı bağlamsal bir şekilde değiştirmek için genellikle bir insan tarafından işlem yapılması gerekir.

Demo: Manuel test

Şimdiye kadar demo web sayfamızda otomatik testler yaptık ve sekiz farklı sorun türünü bulup düzelttik. Artık daha da fazla erişilebilirlik sorunu keşfedip keşfedemeyeceğimizi görmek için manuel kontroller yürütmeye hazırız.

1. Adım

Güncellenen CodePen demomuzda tüm otomatik erişilebilirlik güncellemeleri uygulanmıştır.

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

2. Adım

Manuel test işleminizi başlatmak için farenizi veya dokunmatik yüzeyinizi bir kenara koyun, yalnızca klavyenizi kullanarak DOM'da yukarı ve aşağı hareket edin.

Sorun 1: Görünür odak göstergesi

Görünür odak göstergesi kaldırıldığından ilk klavye sorununu hemen görmeniz veya daha çok görmemeniz gerekir. Demodaki CSS'yi taradığınızda kod tabanına korkunç "outline: none" eklendiğini görürsünüz.

  :focus {
    outline: none;
  }
Bu sorunu çözelim.

Klavye odağı modülünde öğrendiğiniz gibi, web tarayıcılarının kullanıcılara görünür bir odak noktası eklemesine izin vermek için bu kod satırını kaldırmanız gerekir. Bir adım daha ileri gidip dijital ürününüzün estetiğine uygun bir odak göstergesi oluşturabilirsiniz.

:focus {
  outline: 3px dotted #008576;
}

2. sorun: Siparişe odaklanın

Odak göstergesini değiştirdikten ve görünür hale geldikten sonra, sayfada gezinmeyi unutmayın. Bunu yaparken, bültene abone olmak için kullanılan form giriş alanına odaklanmadığını fark edeceksiniz. Negatif bir sekme dizini tarafından doğal odaklanma sıralamasından çıkarıldı.

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

Kullanıcıların bültenimize kaydolmak için bu alanı kullanmasını istediğimizden, girişin tekrar klavyeye odaklanılabilir hale gelmesi için negatif sekme dizinini kaldırmamız veya sıfıra ayarlamamız gerekiyor.

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

3. Adım

Klavye odağı kontrol edildikten sonra görsel ve içerik kontrollerine geçilir.

Demo sayfasında sekmelerle klavye testlerini incelerken, muhtemelen klavyenin farklı tıbbi sorunlarla ilgili paragraflarda görsel olarak gizlenmiş üç bağlantıya odaklandığını fark etmişsinizdir.

Sayfamızın erişilebilir olması için, bağlantıların etrafındaki metinden ayırt edilmesi ve fare üzerine gelindiğinde ve klavye odağında renk olmayan bir stil değişikliğinin bulunması gerekir.

Bu sorunu çözelim.

Paragrafların içindeki bağlantıların öne çıkmasını sağlamak için bağlantıların altını çizmek hızlı bir çözümdür. Bu, erişilebilirlik sorununu çözer ancak ulaşmayı beklediğiniz genel tasarım estetiğine uygun olmayabilir.

Alt çizgi eklememeyi seçerseniz renkleri hem arka plan hem de kopya gereksinimlerini karşılayacak şekilde değiştirmeniz gerekir.

Bağlantı kontrastı kontrol aracı kullanarak demoyu incelerken bağlantı renginin normal boyutlu metin ile arka plan arasındaki 4.5:1 renk kontrastı koşulunu karşıladığını görürsünüz. Ancak altı çizili olmayan bağlantıların da etrafındaki metne göre 3:1 renk kontrastı koşulunu karşılaması gerekir.

Seçeneklerden biri, bağlantı rengini sayfadaki diğer öğelerle eşleşecek şekilde değiştirmektir. Ancak, bağlantı rengini yeşil olarak değiştirirseniz gövde metni, üç öğenin tamamının (bağlantılar, arka plan ve etrafındaki metin) genel renk kontrastı gereksinimlerini karşılayacak şekilde değiştirilmesi gerekir.

Bağlantı metni için WebAIM ekran görüntüsü, gövde metni bağlantısının WCAG A düzeyinde başarısız olduğunu gösteriyor.
Bağlantı ve gövde metni aynı olduğunda test başarısız olur.
WebAIM ekran görüntüsü, bağlantı rengi yeşil olduğunda tüm testlerin başarılı olduğunu gösteriyor.
Bağlantı ve gövde metni farklı olduğunda test başarılı olur.

Sorun 4: Simge rengi kontrastı

Gözden kaçan bir diğer renk kontrastı sorunu sosyal medya simgeleridir. Renk ve kontrast modülünde, gerekli simgelerin arka plana göre 3:1 renk kontrastına uyması gerektiğini öğrendiniz. Ancak demoda sosyal medya simgelerinin kontrast oranı 1,3:1'dir.

Bu sorunu çözelim.

3:1 renk kontrastı gereksinimlerini karşılamak için sosyal medya simgeleri daha koyu griye dönüştürülür.

Renk analizcisinin başarısız simge renk kontrastını gösterdiği demonun ekran görüntüsü.

5. Sorun: İçerik düzeni

Paragraf içeriğinin düzenine bakarsanız metin tamamen yaslanmış olarak görünür. Yazı biçimi modülünde öğrendiğiniz gibi bu durum, bazı kullanıcıların metni okumasını zorlaştırabilecek "boşluk nehirleri" oluşturur.

p.bullet {
   text-align: justify;
}
Bu sorunu çözelim.

Demodaki metin hizalamasını sıfırlamak için kodu text-align: left; olarak güncelleyebilir veya tarayıcılar için varsayılan hizalamanın solda olması nedeniyle bu satırı CSS'den tamamen kaldırabilirsiniz. Devralınan diğer stillerin varsayılan metin hizalamasını kaldırması durumunda kodu test ettiğinizden emin olun.

p.bullet {
   text-align: left;
}

4. Adım

Medikal Gizemler Kulübü demo sitesinin ekran görüntüsü.
Bu resimde gösterildiği gibi demoda tüm manuel sorunlar ele alınmıştır.

Önceki adımlarda açıklanan tüm manuel erişilebilirlik sorunlarını belirleyip düzelttikten sonra sayfanız ekran görüntümüze benzer görünecektir.

Manuel kontrollerinizde bu modülde ele aldığımızdan daha fazla erişilebilirlik sorunu bulmanız mümkündür. Bu sorunların birçoğunu sonraki modülde ele alacağız.

Sonraki adım

Tebrikler! Otomatik ve manuel test modüllerini tamamladınız. Tüm otomatik ve manuel erişilebilirlik düzeltmelerinin uygulandığı güncellenmiş CodePen'i görüntüleyebilirsiniz.

Şimdi, yardımcı teknoloji testlerine odaklanan son test modülüne geçin.

Öğrendiklerinizi sınayın

Manuel erişilebilirlik testi bilginizi test etme

Hangi öğelerin WCAG renk kontrastı standartlarını karşılaması gerekir?

Simgeler
Simgelerin renk kontrastı standartlarını karşılaması gerekir, ancak tek seçenek bunlar değildir.
Başlık
Başlıkların renk kontrastı standartlarını karşılaması gerekir ancak tek seçenek bu değildir.
Gövde metni
Gövde metninin renk kontrastı standartlarını karşılaması gerekir ancak tek seçenek bu değildir.
Yukarıdakilerin tümü
Her öğe, WCAG tarafından yazılan kontrast standartlarını karşılamalıdır.