Dijital Erişilebilirlik Hizmeti: Otomasyon ve Gerçek Kullanıcı Testlerinin Önemi

Birçok marka dijital erişilebilirlik konusunda ilk adımı atarken benzer bir yöntem izliyor:

Bir tool çalıştırılıyor, rapor alınıyor ve sonuç “temiz” çıkıyorsa iç rahatlıyor.

Ama burada kritik bir soru var:

Tool “sorun yok” dedi diye gerçekten erişilebilir mi?

Dijital erişilebilirlikte en büyük yanılgılardan biri şu:

“Bulgu yoksa problem yoktur.”

Oysa gerçek hayatta erişilebilirlik problemlerinin büyük bir kısmı, otomasyon araçlarının göremediği yerlerde yaşanır. Çünkü erişilebilirlik sadece kodun doğru yazılması değil, kullanıcının gerçekten işlemini tamamlayabilmesidir.

Ve bunu en iyi ölçen şey, bir rapor değil: gerçek kullanıcı deneyimidir.

Dijital Erişilebilirlik Hizmeti Nedir?

Dijital erişilebilirlik hizmeti çoğu zaman yalnızca “rapor hazırlama” işi gibi algılanıyor.

Oysa iyi bir erişilebilirlik hizmeti; web sitesi veya mobil uygulamanın tüm kullanıcılar için erişilebilir olmasını sağlayan, sistemli ve sürdürülebilir bir süreçtir.

Bu süreçte iki temel test bacağı vardır:

1) Otomasyon Testleri

Otomasyon testleri, erişilebilirlik açısından sayfa üzerinde hızlı tarama yapan araçlarla yürütülür.

Bunlar genelde eksik label, kontrast problemi, yanlış başlık hiyerarşisi gibi teknik sorunları yakalamada oldukça etkilidir.

Avantajı nettir:

hız + geniş kapsam

2) Gerçek Kullanıcı Testleri

Gerçek kullanıcı testleri ise ekran okuyucu kullanan kullanıcıların (VoiceOver / TalkBack) senaryo bazlı şekilde akışları tamamlamaya çalışmasıyla yapılır.

Burada amaç, “sayfa okunuyor mu?” değil şudur:

Kullanıcı gerçekten işini yapabiliyor mu?

Avantajı nettir:

bağlam + gerçek deneyim

Bu yüzden “accessibility testing” dediğimiz şey, aslında iki parçanın birleşimidir:

• Otomasyon: hız ve tarama gücü
• İnsan testi: deneyim ve gerçeklik

Otomasyon Neden Yeterli Değil?

Otomasyon araçları çok güçlüdür ama sınırlıdır. Çünkü erişilebilirlik problemlerinin büyük kısmı “bağlam” ile ilgilidir. Tool, bağlamı anlayamaz.

Örneğin otomasyonun tespit edemediği bazı kritik problem türleri şunlardır:

Odak Sırası Mantıksızdır Ama Tool Bunu Anlamaz

Klavye veya ekran okuyucu ile ilerlerken odak sırası kullanıcıyı alakasız yerlere götürebilir.

Sayfa teknik olarak çalışıyordur ama kullanıcı “akışı takip edemez.”

ARIA Label Vardır Ama Yanlıştır

Bir buton “button” olarak tanımlanmıştır. Tool bunu doğru sayar.

Ama butonun label’ı örneğin “icon” veya “image” diye okunuyorsa kullanıcı ne işe yaradığını anlayamaz.

Buton Okunuyordur Ama Ne Yaptığı Belli Değildir

Tool “buton var” der.

Ama kullanıcı “Devam Et” mi “Kaydet” mi olduğunu anlayamıyorsa akış biter.

Hata Mesajı Var Ama Ekran Okuyucuya Düşmez

Formda hata mesajı görünürdür, ancak ekran okuyucu bunu seslendirmiyordur.

Kullanıcı yanlış yaptığını fark etmez ve aynı yerde döner durur.

Modal Açılır Ama Kullanıcı İçeride Kilitlenir

Modal ekran açıldığında odak modal içine hapsolmaz ya da kullanıcı çıkış yapamaz.

Tool çoğu zaman bu durumu “hata” olarak göremez.

Bunların hepsi şu duruma yol açar:

WCAG uyumlu görünüp erişilebilir olmamak.

Tabii otomasyonun güçlü olduğu alanları da dürüstçe söylemek gerekir:

Kontrast hataları, eksik label’lar, başlık hiyerarşisi gibi sorunları hızlı yakalamada otomasyon oldukça başarılıdır.

Ama erişilebilirliğin tamamı bu değildir.

Gerçek Kullanıcı Deneyimi: Bir Hata Tüm Akışı Bitirebilir

Erişilebilirliği gerçek yapan şey, kullanıcı yolculuğudur.

Şöyle bir senaryo düşünelim:

Bir kullanıcı uygulamaya giriyor.

• Login ekranını başarıyla geçiyor
• Ürün seçiyor
• Ödeme ekranına geliyor
• Kart bilgilerini giriyor
• Dropdown menüden “Taksit seçimi” yapmak istiyor

Ama dropdown açılıyor, ekran okuyucu menüdeki seçenekleri okumuyor.

Kullanıcı seçeneklerin içinde gezinemiyor.

Devam etmek istiyor ama “Devam Et” butonuna ulaşamıyor çünkü odak sırası dropdown içinde sıkışmış durumda.

Sonuç?

Kullanıcı ödeme adımında takılıyor ve işlemi tamamlayamıyor.

Burada mesele “okunabilirlik” değil.

Mesele şudur:

Erişilebilirlik, kullanıcının işini tamamlayabilmesidir.

Ekran okuyucu kullanıcıları için küçük gibi görünen bir hata, tüm akışı bitirebilir.

Ve bu yalnızca “kullanıcı zorlandı” durumu yaratmaz.

Bu, aynı zamanda şu anlama gelir:

Markaya güven kaybı.

Çünkü kullanıcı kendini dışlanmış hisseder.

Ve çoğu zaman geri dönmez.

Doğru Dijital Erişilebilirlik Hizmeti Nasıl Olmalı?

Gerçekten sürdürülebilir bir dijital erişilebilirlik hizmeti, tek bir testten ibaret olamaz.

Sistemli ve döngüsel ilerlemelidir.

Doğru metodoloji genellikle şu şekilde işler:

1) Otomasyon Taraması ile Ön Analiz

Geniş kapsamlı bir tarama yapılır.

Hızlıca riskli alanlar belirlenir.

2) Uzman Manuel İnceleme

Erişilebilirlik uzmanları, ekran davranışlarını ve kod yapısını manuel kontrol eder.

Çünkü birçok problem “UI davranışı” ile ilgilidir ve otomasyon burada kör kalır.

3) Gerçek Kullanıcı Testleri (Senaryo Bazlı)

VoiceOver / TalkBack kullanan gerçek kullanıcılar kritik akışları test eder:

• kayıt olma
• login
• ödeme
• form doldurma
• müşteri hizmetleri akışları

Bu aşama erişilebilirliğin gerçek kanıtıdır.

4) Bulguların Önceliklendirilmesi

Her bulgu aynı önemde değildir.

Bu yüzden blocker / critical / medium gibi önceliklendirme yapılır.

5) Fix Sonrası Regression Test

Sorunlar düzeltildikten sonra yeniden test edilir.

Çünkü erişilebilirlikte en sık yaşanan risk şudur:

Fix yaparken başka bir şeyi bozmak.

6) Sürekli İzleme ve Release Kontrol

Ürün sürekli değişiyorsa erişilebilirlik de sürekli takip edilmelidir.

Bu yüzden erişilebilirlik bir defalık değil, döngüsel bir süreç olmalıdır.

Bu noktada otomasyon ve gerçek kullanıcı testleri arasındaki ilişkiyi şöyle düşünebilirsin:

Otomasyon = radar

Gerçek kullanıcı testi = savaş alanı

Radar sana “risk var” der.

Ama savaş alanına girmeden ne olacağını gerçekten bilemezsin.

Türkiye’de Regülasyonlar: Yeni Dönemde Risk Daha Büyük

Türkiye’de yayımlanan dijital erişilebilirlik genelgesiyle birlikte birçok kurumun minimum hedefi artık belli:

WCAG 2.2 Level A uyumu

Bu durum erişilebilirliği “iyi niyetli bir gelişim” olmaktan çıkarıp, doğrudan uyumluluk ve risk yönetimi alanına taşıyor.

Burada tehlikeli yanılgı şu:

“Tool temiz çıkardıysa uyumluyuz.”

Oysa gerçek hayatta risk, yalnızca teknik raporlarla değil şu başlıklarda ortaya çıkar:

• kullanıcı şikayetleri
• sosyal medya krizleri
• itibar kaybı
• dava süreçleri
• müşteri kaybı

Özellikle bankacılık, e-ticaret, telekom gibi sektörlerde erişilebilirlik hataları, kritik kullanıcı akışlarını doğrudan etkilediği için risk çok daha büyüktür.

“Erişilebilirlik Hizmeti”nin Gerçek Tanımı

Erişilebilirlik hizmeti:

• sadece tool çıktısı değildir
• sadece WCAG maddesi değildir
• sadece rapor değildir

Gerçek erişilebilirlik hizmeti şudur:

Kullanıcıların gerçekten akışı tamamlayabildiği bir deneyimi garanti altına almak.

İyi bir hizmetin çıktıları net olmalıdır:

• önceliklendirilmiş bug listesi
• video veya somut kanıt
• developer-friendly çözüm önerileri
• fix sonrası doğrulama testleri
• sürdürülebilir takip mekanizması

Ve en kritik mesaj şudur:

Gerçek kullanıcı testi olmadan erişilebilirlik iddiası eksik kalır.

BlindLook Bu Süreci Nasıl Yürütür?

BlindLook’un yaklaşımı, erişilebilirliği sadece “checklist” olarak değil, gerçek kullanıcı yolculuğu olarak ele alır.

Bu kapsamda BlindLook:

• otomasyon taraması
• uzman manuel analiz
• gerçek görme engelli kullanıcı testleri
• web / iOS / Android bazlı değerlendirme
• raporlama + aksiyon takibi
• sürekli takip ve yeniden test yapısı

ile kurumların dijital kanallarında sürdürülebilir bir erişilebilirlik sistemi kurmasına destek olur.

BlindLook’un farkı net bir noktada konumlanır:

WCAG checklist değil, gerçek kullanıcı deneyimi odağı.

2021’den bu yana farklı sektörlerde yürütülen çalışmalarla, erişilebilirliğin sadece uyumluluk değil, ürün kalitesi standardı haline gelmesi hedeflenir.

Özet: En Güçlü Yaklaşım Hibrit Olandır

Kısaca:

• Otomasyon tek başına yeterli değildir
• Gerçek kullanıcı testi erişilebilirliğin kanıtıdır
• En doğru yaklaşım otomasyon + manuel analiz + kullanıcı testinin birleşimidir
• Regülasyonlar erişilebilirliği artık acil bir konu haline getirmiştir

Nereden Başlamalı?

Eğer ürününüzde otomasyonla görünmeyen riskleri görmek istiyorsanız, ilk adım kritik akışlarınızı gerçek kullanıcı deneyimiyle test etmektir.

BlindLook olarak, mevcut dijital kanallarınızı hızlıca değerlendirip size nereden başlamanız gerektiğini gösterebiliriz.

Kısa bir değerlendirme görüşmesiyle süreci birlikte başlatabiliriz.