Ekran Okuyucu Kullanıcılarıyla Mobil Test Oturumu Kurmak

Ekran okuyucuyla yapılan mobil test oturumları, alışıldık moderasyon düzeninin neredeyse tamamını bozar. Ekran paylaşımı yeterli olmaz, görev listesi uzun gelir, kolaylaştırıcının sessiz kalma refleksi işe yaramaz. Aşağıdaki düzen, katılımcıyı bulmaktan kaydı analiz edilebilir hale getirmeye kadar oturumun tek tek adımlarını içeriyor.

Katılımcıyı nereden bulacaksınız

İlk engel yöntem değil, örneklem. Hazır katılımcı havuzları ekran okuyucu kullanan kişileri ya hiç barındırmaz ya da tek haneli sayılarda barındırır, çünkü bu havuzlar genelde kendi kendine doldurulan formlarla kuruluyor ve form erişilebilir değilse orada kimse kalmıyor.

Pratikte işleyen üç yol var. Yerel dernekler ve topluluklarla doğrudan iletişim kurmak, tek tek katılımcı yerine bir ağ açar. Katılan kişilerin çevresine yaptığı yönlendirme, ikinci turu birincisinden kolay hale getirir. Üçüncüsü uzun vadeli olan: kendi davetli panelinizi kurmak.

Panelin kendi tuzağı da burada. Aynı beş kişiyle altı ay test ederseniz, altıncı ayda o beş kişinin ürününüzü ezberlemiş halini ölçersiniz. Kullanım süresi, ekran okuyucu deneyiminin yılı, cihaz platformu ve konuşma hızı gibi eksenlerde çeşitlilik tutmak, panelin ömrünü uzatır.

Oturumu katılımcının ortamında yapın

Uzaktan oturumlar burada ciddi bilgi kaybettirir. Katılımcının telefonu nasıl tuttuğunu, braille klavyeyi nereye koyduğunu, kulaklığı takıp takmadığını, bildirim geldiğinde okuma akışının nasıl bölündüğünü uzaktan göremezsiniz.

Cihaz konusunda taviz vermeyin: katılımcı kendi telefonunu kullanmalı. Bunun sebebi sadece alışkanlık değil. VoiceOver ile TalkBack'in gezinme mantığı birbirinin karşılığı değildir; rotorla başlık başlık ilerlemeye alışmış biri, TalkBack'in okuma denetimlerinde belirgin şekilde yavaşlar. Test cihazı verdiğinizde ölçtüğünüz şey arayüzünüz değil, katılımcının o platforma ne kadar yabancı olduğu olur.

Hazırlık listesi

Kurulum, görme temelli bir oturumdakinin iki katı kadar sürüyor. Oturum saatinden önce hazır olması gerekenler:

• Harici mikrofon: ekran okuyucu sesi ile katılımcının konuşması aynı kayıtta ayırt edilebilmeli.
• Doküman kamerası ya da üstten bakan ikinci bir kamera: parmak hareketleri ve tutuş biçimi ancak böyle görünür.
• Senaryo ve görev metinlerinin basılı kopyası: moderatörün ekranda dolaşması katılımcının sesini bastırır.
• Harici disk: üç kaynaklı kayıt kısa oturumlarda bile hızla büyür.
• Kullanılan ekran okuyucunun temel komutları: katılımcıya bir sorunu tarif ederken doğru terimi kullanmak gerekir.

Görev sayısını da baştan azaltın. Ekran okuyucuyla bir formu doldurmak, aynı formu gözle doldurmaktan birkaç kat uzun sürer; masaüstünde hazırladığınız görev listesini olduğu gibi taşırsanız oturum son görevlere hiç gelmeden biter.

Oturum sırasında konuşmak

Moderatörün sessiz kalıp gözlemlemesi burada işlemiyor, çünkü sessizlik katılımcı için odadan çıkmışsınız anlamına geliyor. Kısa ve nötr sesli işaretler verin, ekipmanda bir ayar yaparken ne yaptığınızı söyleyin, sıradaki göreve geçerken sözle haber verin.

Dil konusunda basit bir değişiklik yeter: "görüyor musunuz" yerine "karşınıza çıktı mı", "bakın" yerine "bulabiliyor musunuz". Bunlar nezaket ayrıntısı değil, sorunun cevaplanabilir olmasıyla ilgili.

Konuşma hızına dokunmayın. Deneyimli kullanıcıların çoğu, varsayılanın çok üzerindeki bir hızda dinler ve siz anlayın diye yavaşlatıldığında kendi kullanım davranışı değişir. Anlamadığınız kısmı kayıttan tekrar dinlersiniz, oturumu yavaşlatmanıza gerek yok.

Kaydı analiz edilebilir hale getirmek

Üç kaynağı ayrı ayrı kaydedip analiz sırasında eşlemeye çalışmak zaman kaybı. Ekran kaydını, üstten kamerayı ve sesi oturumdan hemen sonra tek bir senkron videoya birleştirin. Ekran okuyucunun ne okuduğu ile parmağın nereye dokunduğu arasındaki gecikmeyi ancak eşzamanlı izlerken fark edersiniz, ve sorunların çoğu tam o gecikmede saklı.

Bulguları not ederken ekran okuyucunun okuduğu cümleyi değil, o cümlenin geldiği düğümün ad, rol ve durum üçlüsünü yazmayı tercih ederim. Sebebi şu: "katılımcı düğmenin açık mı kapalı mı olduğunu anlamadı" cümlesi tasarım ekibine bir metin sorunu gibi görünür, oysa karşılığı genellikle koddadır. Özel çizilmiş bir anahtar bileşeni erişilebilirlik ağacına düz metin olarak düşmüşse etiketi doğru okunur ama durumu hiç duyurulmaz. WCAG'nin ad, rol, değer ölçütü tam olarak bunu tarif ediyor ve bulguyu bu dille yazdığınızda düzeltilecek satır belli oluyor.

Otomatik denetim, kendi kendine test, gerçek kullanıcı

Bu üçü birbirinin yerine geçmiyor, sırayla geliyor. Otomatik denetim araçları eksik etiketi, düşük kontrastı, dokunma hedefi boyutunu ucuza yakalar; yapılmaması için sebep yok, ama buldukları şey uyumluluktur, kullanılabilirlik değil.

Geliştiricinin kendi cihazında VoiceOver açıp akışı denemesi ikinci basamak. Bu da faydalı, sınırı şu: siz zaten arayüzün haritasını biliyorsunuz, dolayısıyla test ettiğiniz şey gezinmenin öğrenilebilirliği değil, çalışıp çalışmadığı.

Gerçek kullanıcının cevapladığı soru üçüncüsü: bu ekranda hiç bilmediğiniz bir yerden başlayıp hedefe varılıyor mu, kaç adımda varılıyor, hangi noktada geri dönülüyor. İlk ikisi bu soruyu hiç sormaz. Erişilebilirlik bütçesi sınırlıysa sıralama net: denetim aracını sürekli çalıştırın, kendi testinizi her sürümde yapın, gerçek kullanıcı oturumlarını da akışın değiştiği sürümlere saklayın.