Ekran Okuyucu ile Erişilebilirlik Testi: NVDA ve VoiceOver ile Adım Adım

Neden ekran okuyucuyla test edilir

Erişilebilirlik testi üç ayağa dayanır: otomatik tarama, klavye kontrolü ve yardımcı teknoloji ile manuel test. Otomatik araçlar eksik etiket ya da düşük kontrast gibi mekanik sorunları bulur ama bir sayfanın gerçekten anlaşılır olup olmadığını söyleyemez. W3C WAI da hiçbir aracın tek başına bir sitenin erişilebilirlik standartlarını karşılayıp karşılamadığını belirleyemeyeceğini belirtir ve insan değerlendirmesini şart koşar.

Ekran okuyucu, ekrandaki içeriği sesli okuyan ya da braille çıktıya dönüştüren yardımcı bir teknolojidir. Görme engelli kullanıcılar sayfayı gözle taramak yerine başlıklar, bölgeler ve bağlantılar arasında gezinerek ilerler. Sayfanın bu şekilde kullanılabilir olup olmadığını ancak o yolla test ederek görürsünüz.

Testin amacı kullanıcı deneyimini kendi başınıza uzman düzeyinde yargılamak değildir. Kullanıcı testi yerine geçmez; ama bilinen yaygın sorunları geliştirme sırasında yakalamak için ucuz ve etkili bir yoldur. Gerçek ekran okuyucu kullanıcılarıyla yapılan testler ise ayrıca değerlidir.

Hangi ekran okuyucu ve tarayıcı birlikte denenir

Her platformun kendi ekran okuyucusu vardır. NVDA, Windows için geliştirilen ücretsiz ve açık kaynaklı bir ekran okuyucudur. VoiceOver ise Apple cihazlarının kendi içinde gelen ekran okuyucusudur ve masaüstünde ve mobilde kullanılır. İki araç aynı sayfayı benzer ama birebir aynı olmayan biçimde duyurur.

Ekran okuyucu ve tarayıcı birlikteliği sonucu etkiler. Aynı sayfa farklı birleşimlerde farklı davranabilir. Bu yüzden önce hedef kitlenizin en çok kullandığı platformu belirleyin, sonra en az iki birleşimi deneyin: örneğin Windows’ta NVDA ile bir tarayıcı, Apple cihazında VoiceOver ile onun yerleşik tarayıcısı.

NVDA’da gezinti modunda tek harfli tuşlarla başlıklar ve bölgeler arasında dolaşılır; başlıklar için h, bölgeler için d tuşu kullanılır. Ayrıca bir Elements List penceresi sayfadaki bağlantıları ve başlıkları listeler. VoiceOver’da benzer işi jestler ve bir gezinme çarkı (rotor) görür. Kısayolları ve kullanım ayrıntılarını aracın güncel belgelerinden öğrenin.

Adım adım bir test turu

Düzenli bir tur, rastgele gezintiden daha çok sorun yakalar. Aynı sırayı her sayfada tekrarlayın.

Önce sayfayı fare olmadan açın ve ekran okuyucuyu başlatın. Sayfa başlığını ve sayfa yüklendiğinde duyurulan ilk şeyi dinleyin. Başlığın içeriği doğru anlatıp anlatmadığına bakın.

Sonra yapıyı kontrol edin: başlıklar arasında dolaşın ve başlık hiyerarşisinin sayfanın mantığıyla örtüştüğüne bakın. Bölgeler arasında dolaşın; gezinme, ana içerik ve altbilgi ayrı bölgeler olarak tanınıyor mu?

Sonra etkileşimli öğelere geçin. Bağlantı ve düğmelerin adları tek başına anlamlı mı? “Devam” ya da “tıklayın” gibi adlar bağlamsız okunduğunda belirsizdir. Form alanlarının etiketi okunuyor mu, zorunlu alan ve hata mesajı duyuruluyor mu?

Son olarak dinamik davranışları sınayın: açılır pencere açıldığında odak içine geçiyor mu, kapanınca eski yerine dönüyor mu? Sayfa içinde güncellenen alanlar (sepet toplamı, hata mesajı) duyuruluyor mu?

Her bulguyu not edin.

Sık bulunan sorunlar ve düzeltmeleri

Test turunda tekrar tekrar karşılaşılan sorunlar vardır.

• Adsız ya da belirsiz düğmeler: Yalnız simge içeren düğme “düğme” diye okunur. Düzeltme, anlamlı bir erişilebilir ad vermektir.
• Etiketsiz form alanları: Alanın amacı duyulmaz. Düzeltme, alanı görünür bir etiketle bağlamaktır.
• Bozuk başlık yapısı: Başlıklar görsel boyut için seçilmiş, mantıksal sıra için değil. Düzeltme, başlık düzeylerini içeriğin hiyerarşisine göre ayarlamaktır.
• Eksik ya da gereksiz görsel açıklaması: Anlamlı görselin açıklaması yoksa bilgi kaybolur, süs görseli ise gürültü yaratır. Düzeltme, anlamlıya açıklama vermek ve süsü okunmaz yapmaktır.
• Duyurulmayan dinamik değişiklik: Hata mesajı ya da güncellenen alan sessiz kalır. Düzeltme, değişikliği yardımcı teknolojiye bildiren uygun işaretlemedir.
• Odak kaybı: Açılır pencere kapandığında odak sayfanın başına atlar. Düzeltme, odağı mantıklı bir yere taşımaktır.

Çözümlerde ARIA kullanılacaksa ilk tercih mümkün olduğunca yerel HTML öğeleri olmalı; yanlış ARIA, hiç ARIA olmamasından kötü olabilir.

Bulguları kaydetmek ve süreci kalıcılaştırmak

Bir bulguyu yazarken yalnız “erişilebilir değil” demek yeterli olmaz. Şu bilgileri ekleyin: hangi sayfa ve hangi öğe, hangi ekran okuyucu ve tarayıcı birleşimi, ekran okuyucunun ne duyurduğu ve beklenen duyuru. Sorunu duyduğunuz metinle yazmak, geliştiricinin neyi düzelteceğini netleştirir.

Önem derecesini de belirtin. Bir formu doldurmayı imkânsız kılan sorun, görsel açıklamasındaki küçük eksiklikten ağırdır. Böylece ekip düzeltme sırasını belirleyebilir.

Testi tek seferlik bir denetim olarak değil, geliştirme sürecinin parçası olarak kurun. Yeni bileşen yazıldığında ekran okuyucuyla kısa bir kontrolden geçmesi, sorunların sonradan pahalı düzeltmelere dönüşmesini önler. Tasarım aşamasında da başlık yapısı ve etiketler düşünülmelidir.

Klavye erişilebilirliği, test turunun önkoşuludur; bu yüzden test ekran okuyucuyla başlamadan önce yalnız klavyeyle bir kez yürünmelidir. Erişilebilirliğin hukuki ve iş boyutu ayrı bir değerlendirme gerektirir.

Örnek: üyelik formunu baştan sona gezmek

Kurgusal bir senaryo: bir üyelik formunda ad, e-posta, parola ve bir onay kutusu var; gönder düğmesi sonrası başarı mesajı çıkıyor. Test, fareyi bırakıp sayfaya başlıkla girerek başlar. Sayfa başlığı formun amacını söylüyor mu? Başlıklar arasında dolaşınca form bölümü ve başlığı tanınıyor mu?

Sonra form alanlarına tek tek gelin. Her alanda ekran okuyucu etiketi, alan türünü ve zorunlu olup olmadığını duyurmalıdır. Parola alanında kurallar yalnız görsel olarak yazılmışsa, ekran okuyucu kullanıcısı kuralı öğrenemez. Onay kutusunda metnin bağlantı içerip içermediğine, bağlantının adının tek başına anlamlı olup olmadığına bakın.

Şimdi bilerek hatalı gönderin: boş bırakılan alan için hata mesajı gelince ekran okuyucu bunu duyuruyor mu, odak hatalı alana ya da özet mesaja geçiyor mu? Hata yalnız kırmızı renkle gösteriliyorsa ve duyurulmuyorsa, kullanıcı formun neden gitmediğini anlayamaz. Son olarak başarılı gönderimi deneyin: başarı mesajı duyuruluyor mu, yoksa sayfa sessizce yenileniyor mu?

Her adımda duyulanı olduğu gibi not edin. Birkaç bulgu bile geliştirici için yeterlidir: hangi alan, ne duyuldu, ne beklenirdi.

Bu beceriyi Mindset programlarında nerede çalışırsınız

Arayüz tasarlayan, test eden ya da geliştiren herkes için ekran okuyucu testi, erişilebilirliğin gerçek kullanımda nasıl göründüğünü anlamanın en doğrudan yoludur. UX/UI Bootcamp ve UX / UI Uzmanlığı Sertifika Programı’ndaki Kullanılabilirlik ve Erişilebilirlik modülü, bu testin ait olduğu çerçeveyi kurar; UX / UI Uzmanlığı programındaki Yüksek Doğruluklu Prototip ve Kullanılabilirlik Testi modülü de bulguları tasarıma geri bağlar.