Tarayıcıda Ekran Okuyucu Testi: 5 Dakikada Başla

Bakın şimdi, ekran okuyucu testi deyince çoğu geliştiricinin yüzü hafif geriliyor. Haklılar da. İlk kez VoiceOver açtığımda, 2019 yazında Kadıköy’de küçük bir ajans projesinde çalışıyordum ve cihaz bir anda sayfayı sanki yarış atı gibi okumaya başlamıştı. Ne dediğini yakalayamadım, kapatmayı da beceremedim, kısa süreli bir panik yaşadım… Mantıklı değil mi? ama işin aslı şu ki, korkulacak kadar karmaşık değil (inanın bana)

Bakın, Ekran okuyucu testi, “erişilebilirlik uzmanı olmayı” gerektirmiyor. Çoğu zaman sadece birkaç dakika ayırıp sayfanın nasıl duyulduğunu dinlemek yeterli. Otomatik araçlar güzel bir başlangıç veriyor, evet — ama eksik parçaları çoğunlukla manuel testle görüyorsunuz. Yanlış etiketlenmiş butonlar, saçma heading sırası, klavyeyle ulaşılamayan özel bileşenler… bunlar raporda parlıyor resmen.

Neden ekran okuyucuya kulak vermek gerekiyor?

Açık konuşayım: yalnızca skor peşinde koşmak insanı yanlış yere götürüyor. Geçen ay Levent’te bir fintech ekibine danışmanlık verirken Lighthouse puanı 94’tü; ekip bayağı gururluydu, hani “bitti, tamam” havasındaydılar. Ama form alanlarının yarısı programatik etiket taşımıyordu. Yani ekran gören biri için “idare eder” görünen arayüz, sesli okuma tarafında duvara tosluyordu.

Ciddi fark var.

Bir şey dikkatimi çekti: Bir de şu var: otomasyon her şeyi yakalamıyor. Alt metni “image123” olan görseli görürsünüz belki; ama başlıkların mantıksız sıralandığını, “Gönder” butonunun iki farklı yerde aynı isimle geçtiğini ya da kartların okuma sırasının altüst olduğunu, bunları ancak gerçek kullanımda anlarsınız. Hani bazı şeyler kağıt üstünde tamam görünür ama pratikte dökülür ya… tam öyle.

Erişilebilirlik Skoru Size Yalan Söylüyor: Neye Güvenmeli? yazısında da benzer bir noktaya dokunmuştuk; skor güzel bir sinyal verir. Son karar değildir. Burada da aynı mantık geçerli: ekran okuyucuyu açıp iki tür dolaşınca bazen saatlerce sürecek hata avını beş dakikada yakalarsınız.

Mac’te VoiceOver ile hızlı başlangıç

Mac kullanıyorsanız işiniz kolay. VoiceOver zaten sistemin içinde geliyor, ekstra kurulum istemiyor. Ben bunu ilk kez 2021’de İzmir’de uzaktan çalışan bir tasarım ekibiyle test ederken fark ettim; Safari üzerinde açtığım demo siteyi sadece kısayollarla gezmek şaşırtıcı derecede öğreticiydi. Gerçekten.

VoiceOver’ı açmak için Cmd + F5 yeterli. Bazı MacBook’larda Touch ID tuşuna üç kez basmak da işe yarıyor — evet, biraz tuhaf, ilk duyduğumda ben de öyle düşünmüştüm. Sonra VO + Sağ Ok ile öğeler arasında ilerliyorsunuz; burada VO demek Ctrl + Option (yanlış duymadınız). Kapatmak için yine Cmd + F5. Bu konuyla ilgili Muse’un Akıllı Uyandırma Hamlesi: Alarmı Beyniniz Seçiyor yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili Planeta Libre: Ñoño Bloglarının Sessiz Buluşma Noktası yazımıza da göz atmanızı tavsiye ederim.

Durun, bir saniye. İki Site, Bir Saldırı: Chime ve Pinterest Neden Düştü? yazımızda bu konuya da değinmiştik.

Kullanırken neye bakmalısınız?

Ekran okuyucunun söylediği ilk şeylere dikkat edin: sayfa başlığı anlamlı mı, ilk odaklandığı öğe beklediğiniz şey mi, buton isimleri tek başına anlam veriyor mu? “Buraya tıklayın” yerine “Sepete ekle” gibi net ifadeler duyulmalı. Bu çok basit gibi duruyor — ve öyle aslında — ama pratikte en sık kaçan yerlerden biri bu.

Ekran okuyucu testi yaparken amaç her şeyi kusursuz görmek değil; bariz sürtünmeleri yakalamak. Bir sayfa beş dakikada anlaşılmıyorsa kullanıcı için de kolay değildir.

Windows tarafında NVDA neden hâlâ favori?

Şunu söyleyeyim, NVDA ücretsiz ve açık kaynak. Bu kadar. Kurumsal projelerde bunu özellikle seviyorum çünkü ekip içinden herkes indirip deneyebiliyor; lisans bekleme derdi yok, onay zinciri yok, direkt hallediyorsunuz. Peki bunu neden söylüyorum? Bir startup’ta bu rahatlık bayağı kritik oluyor, hani bürokratik engel olmadan “hemen deneyelim” diyebilmek büyük şey.

Bir dakika — bununla bitmedi.

NVDA’yı nvaccess.org üzerinden indiriyorsunuz ve kurulum sonrası tarayıcı içindeki gezinme için oldukça kullanışlı kısayollar sunuyor. Ok tuşlarıyla temel hareketleri yapabiliyorsunuz; H ile sonraki başlığa atlamak ise özellikle hızlı tarama için ilaç gibi geliyor.

Birkaç temel kısayol

İşlem	Kısayol
Sıradaki öğeye git	Aşağı Ok
Bazı modlarda başlıklara geç	H
Tüm bağlantıları listele	K veya Insert + F7
Sesi duraklat / aç-kapat davranışı kontrol etme	Insert + S / Ctrl

NVDA’nın Browse mode davranışı yeni başlayanlar için bayağı iyi çünkü tek harfle gezinme mantığını hızlıca kavratıyor. Ama küçük bir uyarı düşeyim: fazla güvenmeyin. Bazı özel bileşenler klavye odağını garip biçimde yiyebiliyor ve siz bunu ancak manuel dolaşınca fark ediyorsunuz. Güzel araç, ama kör güvenmek olmaz.

Bence asıl mesele şu beş kontrol noktasında yatıyor

Ekran okuyucuyla sayfayı dinlerken ben hep aynı mini kontrol listesini kullanıyorum. Bunu ilk kez Berlin’de çalışan bir ürün ekibine anlatmıştım; o toplantıda herkes not aldı çünkü konu teoride büyük görünüyor. Uygulamada aslında çok sadeleşiyor.

1. Sayfa başlığı: Tarayıcı sekmesinde ve ekran okuyucuda anlamlı mı?
2. Başlık yapısı: H1’den aşağıya doğru düzen var mı?
3. Labele sahip alanlar: Form alanları ne olduklarını söylüyor mu?
4. Etkileşimli öğeler: Klavyeyle erişiliyor mu?
5. Sıra: Görsel düzen ile okuma sırası birbirini tutuyor mu? — ciddi fark yaratıyor

Küçük startup ile kurumsal ekip arasında fark ne?

Yani, Küçük bir startup’ta hedef genelde hızlı kazanımlar oluyor; yani giriş formu düzgün mü, ana CTA anlaşılıyor mu, ödeme akışı kör kullanıcıya duvar örüyor mu… bunlara bakarsınız ve çok şey çözersiniz.

Kurumsal tarafta ise hikâye biraz değişiyor. İç sistemler kalabalık oluyor, component (belki yanılıyorum ama) kütüphaneleri büyüyor ve sorun tek sayfadan çıkıp bütün tasarım sistemine yayılıyor. Orada test yaklaşımı daha disiplinli olmalı — hatta ben böyle ekiplerde haftalık kısa erişilebilirlik oturumu öneriyorum.

Neleri hemen fark edersiniz?

Dürüst olayım, ekran okuyucu testi ilk bakışta biraz ham gelir… hatta beklediğim kadar pürüzsüz olmayabilir dedirten anlar yaşatır! Ama tam da bu yüzden değerli oluyor. En çok da üç şey hemen göze çarpıyor: anlamsız alternatif metinler, etiketsiz input’lar ve görünüşte tıklanabilir olup gerçekte odak alamayan bileşenler.

Tarayıcıda Çalışan Sıfır Kurulumlu API Yük Testi, bana genelde aynı şeyi hatırlatıyor: araç seçimi önemli ama asıl kazanç yöntemi sade tuttuğunuzda geliyor. Burada da durum benzer; ağır platformlara boğulmadan birkaç kısayolla ciddi sinyal alabiliyorsunuz.

Kendi test rutinim nasıl?

Açık konuşayım… önce ana sayfaya giriyorum, sonra direkt form içeren bir alt sayfaya geçiyorum (buna dikkat edin). Sorunların çoğu orada çıkıyor diye düşünüyorum. Ardından başlıklarda geziniyorum, linklerin isimlerini dinliyorum ve tab sırasını kontrol ediyorum. Eğer üç dakikada akış kafamda oturmuyorsa kullanıcı tarafında iş zor demektir.

// Hızlı manuel kontrol akışı
1) Sayfa başlığını dinle
2) Başlıklarda dolaş
3) Form alanlarını oku
4) Link adlarını tek tek dinle
5) Tab sırasını test et
6) Anlamsız/bozuk yerleri not al
7) Düzelt → tekrar dene

Erişilebilirliği geliştirmek için pratik ipuçları

Bazen çözüm sandığınızdan basit çıkıyor. Mesela düğmeye yalnızca ikon koyup yanında yazı bırakmamak kulağa modern geliyor olabilir… fakat ekran okuyucu açısından ortalık karışıyor. Peki bunu neden söylüyorum? İkonun anlamını taşıyan aria-label ya da görünür metin olmadan o düğme neredeyse hayalet gibi kalıyor.