Manuel testlerle ilgili temel bilgiler
Manuel erişilebilirlik testi, otomatik araçların bulamadığı sorunları tespit etmek için klavye, görsel ve bilişsel testler, araçlar ve teknikler kullanır. Otomatik araçlar, WCAG'de tanımlanan tüm başarı ölçütlerini kapsamadığından otomatik erişilebilirlik testleri yapmanız ve test etmeye devam etmeniz çok önemlidir.
Teknoloji ilerledikçe otomatik araçlarla daha fazla test yapılabilir ancak şu anda geçerli tüm WCAG kontrol noktalarını kapsamak için test protokollerinize hem manuel hem de yardımcı teknoloji kontrolleri eklenmesi gerekir.
Manuel erişilebilirlik testlerinin avantajları:
- Oldukça basit ve hızlı bir şekilde çalıştırılabilir.
- Yalnızca otomatik testlere kıyasla daha yüksek oranda sorun yakalama
- Başarı için az araç ve uzmanlık gerekir.
Manuel erişilebilirlik testlerinin dezavantajları:
- Otomatik testlere kıyasla daha karmaşık ve zaman alıcıdır.
- Geniş ölçekte tekrarlanması zor olabilir.
- Test çalıştırmak ve sonuçları yorumlamak için daha fazla erişilebilirlik uzmanlığı gerektirir.
Otomatik bir araç tarafından algılanabilen erişilebilirlik öğeleri ve ayrıntıları ile algılanamayanları karşılaştırın.
Manuel test türleri
Web sayfanızın veya uygulamanızın dijital erişilebilirlik açısından uygunluğunu değerlendirirken göz önünde bulundurmanız gereken birçok manuel araç ve teknik vardır. Manuel testlerde en çok odaklanılan üç alan klavye işlevselliği, görsel odaklı incelemeler ve genel içerik kontrolleridir.
Bu modülde bu konuların her birini genel olarak ele alıyoruz. Ancak aşağıdaki testler, yapabileceğiniz veya yapmanı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ünüz ile ekibinizin ihtiyaçlarına yönelik kendi odaklanmış manuel test kontrol listenizi oluşturmanızı ö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 öğrendiğimiz gibi bu durum, görme engelli olmayan ve yalnızca klavye kullananlar, az gören/görme engelli ekran okuyucu kullanıcıları ve içeriğin klavye ile erişilebilir olmasını gerektiren teknolojiyi kullanan ses tanıma yazılımı kullanıcıları da dahil olmak üzere tüm kullanıcı türlerini 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ırası mantıklı ve sezgisel mi?
- Klavye odağı göstergesi her zaman görünür mü?
- Odaklanmayı engellememesi gereken bir öğede takılıp kalabilir misiniz?
- Odaklanmayı engellemesi gereken bir öğenin arkasında veya etrafında gezinebiliyor musunuz?
- Odaklanan bir öğe kapatıldığında odak göstergesi mantıklı bir yere geri döndü mü?
Klavye işlevinin etkisi büyük olsa da test prosedürü oldukça basittir. Tek yapmanız gereken farenizi bir kenara bırakmak veya küçük bir JavaScript paketi yükleyip web sitenizi yalnızca klavyenizi kullanarak test etmek. Klavye testi için aşağıdaki komutlar gereklidir.
Görsel denetimler
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 ya da tarayıcı yakınlaştırma gibi araçlardan yararlanır.
Görsel kontroller size şunları söyleyebilir:
- Otomatik bir aracın tespit edemediği renk kontrastı sorunları var mı? Örneğin, renk geçişi veya resmin üzerindeki metinler.
- Başlık, liste ve diğer yapısal öğeler gibi görünen 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, flaş veya animasyon var mı?
- İçerikte uygun aralıklar var mı? 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üzenlere, harekete ve renklere odaklanan görsel testlerin aksine, içerik kontrolleri sayfadaki kelimelere odaklanır. Yalnızca metnin kendisine bakmakla kalmamalı, aynı zamanda bağlamı inceleyerek başkaları için anlamlı olduğundan emin olmalısınız.
İçerik kontrolleri, aşağıdaki gibi soruları yanıtlamanıza yardımcı olur:
- Sayfa başlıkları, başlıklar ve form etiketleri net ve açıklayıcı mı?
- Resim alternatifleri kısa, doğru ve faydalı mı?
- Anlam veya bilgi aktarmanın tek yolu olarak yalnızca renk mi kullanılıyor?
- Bağlantılar açıklayıcı mı yoksa "daha fazla bilgi" veya "burayı tıklayın" gibi genel metinler mi kullanıyorsunuz?
- Sayfadaki dilde herhangi bir değişiklik var mı?
- Anlaşılır bir dil kullanılıyor mu ve kısaltmalar ilk kez kullanıldığında açıkça belirtiliyor mu?
Bazı içerik kontrolleri kısmen otomatikleştirilebilir. Örneğin, "Burayı tıklayın" ifadesini kontrol eden ve değişiklik yapmanızı öneren bir JavaScript linter'ı yazabilirsiniz. Ancak bu özel çözümlerin, metni bağlama uygun bir şekilde değiştirmek için genellikle bir kullanıcıya ihtiyacı vardır.
Demo: Manuel test
Şimdiye kadar demo web sayfamızda otomatik testler yaptık ve sekiz farklı sorun türü bulup düzelttik. Artık daha fazla erişilebilirlik sorunu tespit edip edemeyeceğimizi görmek için manuel kontroller yapmaya hazırız.
1. Adım
Güncellenen CodePen demomuzda, otomatik erişilebilirlik güncellemelerinin tümü uygulanmıştır.
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.
2. Adım
Farenizi veya izleme dörtgeninizi bir kenara bırakarak manuel test sürecinizi başlatın ve yalnızca klavyenizi kullanarak DOM'da yukarı ve aşağı gidin.
1. sorun: Görünür odak göstergesi
Görünür odak göstergesi kaldırıldığından ilk klavye sorununu hemen görmelisiniz (daha doğrusu görmemelisiniz). Demodaki CSS'yi taradığınızda, kod tabanına korkunç "outline: none" özelliğinin eklendiğini görmeniz gerekir.
:focus {
outline: none;
}
Bu sorunu düzeltelim.
Klavye odağı modülünde öğrendiğiniz gibi, web tarayıcılarının kullanıcılar için görünür bir odak eklemesine izin vermek üzere bu kod satırını kaldırmanız gerekir. Bir adım daha ileri giderek dijital ürününüzün estetiğine uygun şekilde tasarlanmış bir odak göstergesi oluşturabilirsiniz.
:focus {
outline: 3px dotted #008576;
}
2. sorun: Odaklanma sırası
Odak göstergesini değiştirdikten ve görünür hale getirdikten sonra sayfada sekme tuşunu kullanarak ilerleyin. Bu işlemi yaparken bültene abone olmak için kullanılan form giriş alanının odaklanmadığını fark edeceksiniz. Negatif tabindex ile doğal odak sırasından kaldırılmıştır.
<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>
Kullanıcıların bu alanı bültenimize kaydolmak için kullanmasını istediğimizden, girişin tekrar klavye odaklanabilir hale gelmesi için tek yapmamız gereken negatif tabindex'i kaldırmak veya sıfıra ayarlamaktır.
<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.
3. sorun: Bağlantı rengi kontrastı
Klavye testlerini yaparken demo sayfasında yukarı ve aşağı sekme tuşuna bastığınızda klavyenin, farklı tıbbi durumlarla ilgili paragraflardaki görsel olarak gizlenmiş üç bağlantıya odaklandığını fark etmişsinizdir.
Sayfamızın erişilebilir olması için bağlantılar, çevrelerindeki metinden farklı olmalı ve fareyle üzerine gelindiğinde ve klavye odağı kullanıldığında renk dışı bir stil değişikliği içermelidir.
Sorunu düzeltelim.
Hızlı bir çözüm olarak, paragraflardaki bağlantıları öne çıkarmak için bu bağlantıların altını çizebilirsiniz. Bu yöntem, erişilebilirlik sorununu çözse de genel tasarım estetiği hedeflerinize uygun olmayabilir.
Alt çizgi eklememeyi tercih ederseniz hem arka plan hem de metin için şartları karşılayacak şekilde renkleri değiştirmeniz gerekir.
Bağlantı kontrastı kontrol aracı kullanarak demoya baktığınızda bağlantı renginin, normal boyutlu metin ve arka plan arasında 4,5:1 renk kontrastı şartını karşıladığını görürsünüz. Ancak altı çizili olmayan bağlantılar, çevrelerindeki metinle 3:1 renk kontrastı şartını da karşılamalıdır.
Bağlantı rengini sayfadaki diğer öğelerle eşleşecek şekilde değiştirebilirsiniz. Ancak bağlantı rengini yeşile değiştirirseniz gövde metni de üç öğe (bağlantılar, arka plan ve çevreleyen metin) arasındaki genel renk kontrastı şartlarını karşılayacak şekilde değiştirilmelidir.
4. sorun: Simge renk kontrastı
Kaçırılan bir diğer renk kontrastı sorunu da sosyal medya simgeleridir. Renk ve kontrast modülünde, temel simgelerin arka planla 3:1 renk kontrastı sağlaması gerektiğini öğrenmiştiniz. Ancak demoda, sosyal medya simgelerinin kontrast oranı 1, 3:1'dir.
Sorunu düzeltelim.
3:1 renk kontrastı şartlarını karşılamak için sosyal medya simgeleri daha koyu bir gri renge dönüştürülür.
5. sorun: İçerik düzeni
Paragraf içeriğinin düzenine baktığınızda metnin tamamen yaslandığını görürsünüz. Tipografi 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;
}
Demodaki metin hizalamasını sıfırlamak için kodu text-align: left; olarak güncelleyebilir veya bu satırı CSS'den tamamen kaldırabilirsiniz. Tarayıcılar için varsayılan hizalama soldur. Diğer devralınan stillerin varsayılan metin hizalamasını kaldırması ihtimaline karşı kodu test ettiğinizden emin olun.
p.bullet {
text-align: left;
}
4. Adım
Önceki adımlarda belirtilen tüm manuel erişilebilirlik sorunlarını belirleyip düzelttikten sonra sayfanız, ekran görüntümüzdeki gibi görünmelidir.
Manuel kontrollerinizde, bu modülde ele aldığımızdan daha fazla erişilebilirlik sorunu bulabilirsiniz. Bu sorunların birçoğunu sonraki modülde ele alacağız.
Sonraki adım
Tebrikler! Otomatik ve manuel test modüllerini tamamlamış olmanız gerekir. Tüm otomatik ve manuel erişilebilirlik düzeltmelerinin uygulandığı güncellenmiş CodePen'imizi inceleyebilirsiniz.
Şimdi yardımcı teknoloji testi odaklı son test modülüne geçin.