Uzmanlar İçin Screen Reader Testleri ve Temel Hata Noktaları

Birçok ekip screen reader testini, birkaç alanı Tab tuşuyla gezip etiketlerin okunup okunmadığını kontrol etmek sanıyor.

Oysa screen reader (ekran okuyucu), görme engelli kullanıcıların dijital ürünleri kullanabilmesi için ekrandaki içerikleri ve arayüz bileşenlerini sesli olarak aktaran bir yardımcı teknolojidir. Kullanıcı, ekranı görerek değil; bu sesli yönlendirmeler üzerinden sayfa içinde ilerler ve işlemlerini tamamlar.

Ekran okuyucu testleri, bir ürünün gerçekten kullanılabilir olup olmadığını gösterir.

Okunması, kullanılabilir olduğu anlamına gelmez.

Çünkü ekran okuyucu kullanan bir kullanıcı için deneyim, etiketlerden değil akıştan oluşur.

Bu yazı, ekran okuyucu testlerini gerçekten doğru yapanlarla

“kontrol ettik” diyenler arasındaki farkı netleştirmek için var.

2. Ekran okuyucu testi nedir, ne değildir?

Ekran okuyucu testi, bir arayüzün yardımcı teknolojilerle  senaryo bazlı görevleri bağımsız şekilde tamamlatıp tamamlatmadığını ölçer. Bu testin odağında yalnızca “seslendiriyor mu?” sorusu değil, kullanıcı gerçekten ne anlıyor ve ne yapabiliyor? sorusu vardır.

Ekran okuyucular, görsel arayüzü okumaz; arayüzün kodla tanımlanmış anlamını kullanıcıya aktarır.

Bu yüzden test edilen şey, tasarım değil; tasarımın yardımcı teknolojilere doğru çevrilip çevrilmediğidir.

En yaygın kullanılan ekran okuyucu programları

Gerçek bir test süreci, birden fazla ekran okuyucuyu kapsamalıdır:

• NVDA (Windows – ücretsiz)
• Web erişilebilirlik testlerinde en yaygın kullanılan araçtır.
• HTML semantiği, odak sırası ve ARIA kullanımı hatalarını çok net gösterir.

• JAWS (Windows – ücretli)
• Kurumsal kullanıcılar arasında yaygındır.
• NVDA’dan farklı seslendirme ve gezinme davranışları vardır;
• NVDA’da çalışan bir akış JAWS’ta bozulabilir.

• VoiceOver (iOS & macOS)
• iPhone ve Mac kullanıcıları için varsayılan screen reader’dır.
• Dokunma hareketleri, rotor kullanımı ve odak mantığı web’den tamamen farklıdır.

• TalkBack (Android)
• Android ekosisteminde erişilebilirliğin gerçek test alanıdır.
• Gesture davranışları, odak sırası ve geri bildirim zamanlaması kritik rol oynar.

Bu araçların her biri, aynı arayüzü farklı şekilde deneyimler. Bu yüzden tek bir screen reader ile yapılan test, hiçbir zaman yeterli değildir.

Ekran okuyucu testinde aslında ne ölçülür?

Gerçek bir test şu soruların cevabını arar:

• Kullanıcı sayfaya girdiğinde nerede olduğunu anlayabiliyor mu?
• Tüm elementlere klavye ile erişilebiliyor mu?
• Tüm işlemler klavye ile yapılabiliyor mu?
• Odak sırası kullanıcı deneyimine uygun mu?
• Bir butonun işlevi okunma anında anlaşılabiliyor mu?
• İşlem tamamlandığında sistem bunu doğru anda ve doğru şekilde bildiriyor mu?
• Hata oluştuğunda kullanıcı neyi yanlış yaptığını duyabiliyor mu?
• Aynı bilgi gereksiz tekrarlarla kullanıcıyı yoruyor mu?
• Başlık hiyerarşisi ve sayfa yapısı mantıklı mı?
• Modal açıldığında odak doğru yere gidiyor ve geri dönüyor mu?

Bu soruların hiçbiri otomatik test araçlarıyla yanıtlanamaz.

Çünkü otomasyon, kodu görür; deneyimi görmez.

Neden “okunuyor” olmak yeterli değildir?

Bir butonun “okunması”, onun anlaşılır olduğu anlamına gelmez.

Örneğin:

• "Button" diye okunan bir buton - ne işe yaradığı hiç belli değil
• "icon-send-24px.svg" diye okunan gönder butonu - dosya adı okunuyor, işlev anlaşılmıyor
• "Tıklayın" linki - nereye gittiği, ne yapacağı belirsiz
• Form gönderildi ama hiçbir geri bildirim okunmadı - kullanıcı işlemin başarılı olup olmadığını bilmiyor
• Açılır menü açıldı ama "expanded" durumu bildirilmedi - kullanıcı menünün açık olduğunu anlamıyor

Bu durumda kullanıcı, teknik olarak sayfayı kullanıyor gibi görünü  ama deneyim fiilen kırılmıştır.

İşte ekran okuyucu testinin amacı tam olarak budur: Okunan ile anlaşılan arasındaki farkı ortaya çıkarmak.

Gerçek ekran okuyucu program testi neyi hedefler?

Gerçek bir ekran okuyucu program testi, WCAG’in 4 temel prensibinin kullanıcı deneyiminde gerçekten karşılanıp karşılanmadığını ölçer:

Algılanabilirlik (Perceivable), İşletilebilirlik (Operable), Anlaşılabilirlik (Understandable) ve Sağlamlık (Robust).

Bu yüzden gerçek bir test:

• Etiketleri değil, algılanabilirliği ve anlamı test eder.
• Bileşenleri değil, işletilebilirliği ve akışları test eder.
• Kod uyumunu değil, anlaşılabilirliği ve kullanıcı bağımsızlığını ölçer.
• Sadece “çalışıyor mu?”ya değil, farklı ekran okuyucularda sağlam şekilde çalışıyor mu? sorusuna bakar.

Bu nedenle ekran okuyucu program testleri, erişilebilirlik denetiminin en kritik ve en ayırt edici katmanıdır.

Uzmanların bile en sık yaptığı 5 kritik hata

Bu bölüm, sahada en çok gördüğümüz kırılma noktalarını özetler:

1️⃣ Etiket var sanmak

Bir bileşen etiketli olabilir ama yanlış bağlamda okunduğunda kullanıcıya hiçbir şey ifade etmez.

Örneğin bir form alanı “Seç” diye okunabilir.

Ama kullanıcı neyi seçtiğini (şehir mi, teslimat yöntemi mi, kart mı?) anlayamıyorsa bu etiket teknik olarak var olsa bile pratikte işlevsizdir.

2️⃣ Lineerlik varsayımı

Ekran okuyucu deneyimi, görsel tasarımla aynı sırada ilerlemez.

Odak sırası bozuksa, kullanıcı akışı parçalanır.

3️⃣ Sadece NVDA ile test etmek

NVDA önemli bir araçtır ama tek gerçek değildir.

JAWS, VoiceOver ve TalkBack farklı davranır.

Bir platformda çalışan akış, diğerinde tamamen kırılabilir.

4️⃣ Senaryo yerine bileşen test etmek

Kullanıcılar butonlara değil, işlere gelir.

Senaryo test edilmeden yapılan test, gerçek kullanımı ölçmez.

5️⃣ Hata geri bildirimini test etmemek

Bir hata mesajı okunmuyorsa, kullanıcı neyi yanlış yaptığını anlayamaz.

Bu, erişilebilirlikte en sık gözden kaçan ama en yıkıcı hatadır.

Gerçek bir ekran okuyucu testi nasıl yapılır?

Ekran okuyucu testleri, “okunuyor mu?” kontrolü değildir. Bir kullanıcının, bir işi başından sonuna bağımsız tamamlayıp tamamlayamadığını ölçer.

Bu nedenle gerçek bir test 4 temel adımdan oluşur:

1. Senaryo tanımı

Test, bileşenleri değil, gerçek görevleri kapsar.

Giriş yapmak, form göndermek, ödeme tamamlamak gibi akışlar baştan sona test edilir.

2. Platform ayrımı

Aynı senaryo web, iOS ve Android’de ayrı ayrı değerlendirilir.

Çünkü NVDA, JAWS, VoiceOver ve TalkBack aynı arayüzü farklı okur.

3. Odak ve geri bildirim kontrolü

Kullanıcı her adımda şunu duyabiliyor mu?

• Neredeyim?
• Ne yaptım?
• Şimdi ne oldu?

Hata, başarı ve dinamik içerik geri bildirimleri bu noktada belirleyicidir.

4. Sonuç doğrulaması

Kullanıcı işlemin tamamlandığını kendi başına anlayabiliyorsa test başarılıdır.

Tereddüt varsa, deneyim kırılmıştır.

Gerçek ekran okuyucu testleri; etiketleri değil, anlamı, bileşenleri değil, akışı ölçer.

Regülasyonlar neden ekran okuyucu testini ciddiye alıyor?

Türkiye’de 21 Haziran 2025’te yayımlanan dijital erişilebilirlik genelgesi, erişilebilirliği ilk kez bu kadar net bir şekilde kullanılabilirlik düzeyinde ele alıyor.

Genelge, yalnızca “WCAG kriterleri işaretlenmiş mi?” sorusuna değil,

engelli bireylerin dijital hizmetleri fiilen kullanıp kullanamadığına odaklanıyor.

Bu, denetim yaklaşımında önemli bir kırılma anlamına geliyor.

Artık erişilebilirlik denetimlerinde şu sorular öne çıkıyor:

• Kullanıcı, başkasına ihtiyaç duymadan işlemi tamamlayabiliyor mu?
• Bir hata oluştuğunda, neyi yanlış yaptığını anlayabiliyor mu?
• Süreç boyunca yönünü kaybetmeden ilerleyebiliyor mu?
• İşlem tamamlandığında bunu sistem açıkça bildiriyor mu?

Genelgenin ruhu tam olarak budur:

Teknik uyumun ötesine geçmek ve gerçek kullanıcı deneyimini esas almak.

Bu nedenle “otomatik testlerden geçtik” ya da “etiketler mevcut” gibi yaklaşımlar, denetim perspektifinde artık yeterli kabul edilmez.

ekran okuyucu testleri, bir platformun yalnızca erişilebilir olup olmadığını değil, kullanılabilir olup olmadığını ortaya koyan en kritik doğrulama katmanıdır.

Kısacası:

21 Haziran 2025’te yayınlanan Dijital Erişilebilirlik Genelgesiyle birlikte soru şuna dönüşmüştür:

“Uyumlu mu?” değil, “çalışıyor mu?”

BlindLook ekran okuyucu testlerini neden farklı yapar?

BlindLook, ekran okuyucu testlerini yalnızca teknik bir uygunluk kontrolü olarak değil, gerçek kullanıcı deneyiminin doğrulanması olarak ele alır.

Çünkü erişilebilirliğin başarısı, bir kriterin sağlanmasıyla değil, kullanıcının bir işi bağımsız ve kesintisiz şekilde tamamlayabilmesiyle ölçülür.

2021’dan bu yana BlindLook’un sahada edindiği deneyim, şunu net biçimde gösterdi:

Otomatik testlerden geçen ve WCAG kriterlerini “işaretleyen” birçok platform, ekran okuyucu kullanan kullanıcılar için hâlâ kullanılamaz durumdadır.

Bu yüzden BlindLook yaklaşımı, denetimi rapor üretmek için değil, deneyimi gerçekten çalışır hale getirmek için kurgular.

BlindLook’ta ekran okuyucu test süreci nasıl ilerler?

1. Test edilecek kullanıcı akışları belirlenir

Test süreci, ürün ekipleriyle birlikte kritik kullanıcı yolculuklarının (kayıt olma, giriş yapma, ödeme, randevu alma vb.) netleştirilmesiyle başlar. Böylece test, rastgele ekran kontrolü değil, gerçek iş süreçlerini kapsayan bir değerlendirmeye dönüşür.

2. Otomasyon ile ön taramalar gerçekleştirilir

Belirlenen akışlar doğrultusunda, temel erişilebilirlik kontrolleri otomasyon araçlarıyla taranır. Bu aşama hızlı bir ön görünürlük sağlar ve yüksek riskli alanların önceliklendirilmesine yardımcı olur.

3. Görme engelli test uzmanlarıyla senaryo bazlı test yapılır

BlindLook’un en kritik farkı, testlerin dijital erişilebilirlik alanında deneyimli görme engelli erişilebilirlik test uzmanları tarafından yürütülmesidir. Testler “okunuyor mu?” sorusuna değil, “bu işlem baştan sona bağımsız şekilde yapılabiliyor mu?” sorusuna odaklanır.

4. Bulgular teknik analizden geçirilir ve doğrulanır

Test sırasında tespit edilen sorunlar, erişilebilirlik uzmanlarımız tarafından teknik olarak analiz edilir. Odak sırası, bileşen davranışları, ARIA kullanımı ve geri bildirim mekanizmaları doğrulanarak bulgunun kök nedeni netleştirilir.

5. Geliştirici ekipler için teknik yönlendirme ile raporlanır

Bulgular yalnızca problem tanımıyla değil, geliştirici ekiplerin hızlı aksiyon alabilmesi için çözüm önerileriyle birlikte raporlanır. Her bulgu için:

• sorunun hangi platformda ortaya çıktığı (Web / iOS / Android)
• kullanıcıya etkisi
• önerilen düzeltme yaklaşımı
• net biçimde paylaşılır.

6. İzleme ve tekrar testlerle süreklilik sağlanır

Erişilebilirlik, tek seferlik bir kontrol değil; sürekli korunması gereken bir kalite standardıdır. Yeni geliştirmeler ve release’ler sonrası testler tekrarlanır, böylece erişilebilirliğin zaman içinde bozulmasının önüne geçilir.

Sonuçta ne değişir?

BlindLook ile yapılan ekran okuyucu testleri:

• Rapor üretmek için değil, deneyimi düzeltmek için yapılır
• Geliştirici ekiplerin gerçekten uygulayabileceği çıktılar üretir
• Regülasyonlara uyumu kâğıt üzerinde değil, sahada sağlar
• Erişilebilirliği geçici bir görev değil, kalıcı bir standart haline getirir

BlindLook’un farkı tam olarak burada başlar:

ekran okuyucu testlerini bir kontrol listesi değil,

kullanıcının dijital dünyayla kurduğu bağı doğrulayan bir sistem olarak ele almak.

Kısaca Özetlemek Gerekirse

Screen reader testleri, erişilebilirliğin en kritik doğrulama katmanıdır. Ancak yalnızca doğru yapıldığında.

Etiketler okunabilir olabilir,  kod WCAG’e uygun görünebilir, otomatik testler temiz sonuç verebilir. Ama bir kullanıcı işlemi bağımsız tamamlayamıyorsa, erişilebilirlik yoktur.

Gerçek screen reader testleri; etiketleri değil, anlamı,  bileşenleri değil, akışı, teknik uyumu değil, kullanıcı bağımsızlığını ölçer.

BlindLook, 2019’dan bu yana erişilebilirliği tam olarak bu yerden ele alır.

Eğer screen reader testlerini bir kontrol listesi değil,

gerçek kullanıcı deneyiminin doğrulaması olarak ele almak istiyorsanız,

BlindLook’un uzman yaklaşımıyla tanışabilirsiniz.

Detaylı bilgi ve iş birliği için bizimle buraya tıklayarak iletişime geçin.