Mobil Erişilebilirlikte Otomasyonun Kaçırdıkları: “Mobile a11y”de Kör Noktalar

Mobil erişilebilirlikte (mobile a11y) otomasyon araçları çok değerlidir: hızlı tarar, tutarlılık sağlar ve regresyonları yakalamaya yardımcı olur. Ancak “geçti” raporu, gerçek kullanıcılar için erişilebilir bir deneyim olduğu anlamına gelmez. Çünkü mobil deneyim; dokunma, hareket, ekran okuyucu jestleri, farklı sistem ayarları, küçük ekran alanı ve anlık bağlam (tek elle kullanım, güneş ışığı, düşük bağlantı) gibi otomasyonun tam olarak modelleyemediği koşullara dayanır.

Bu yazıda, otomasyonun mobil a11y’de sıkça kaçırdığı alanları WCAG perspektifiyle ele alacak; iOS/Android özelinde neleri manuel doğrulamanız gerektiğini ve daha sağlam bir kalite süreci için nasıl bir yaklaşım izleyebileceğinizi anlatacağız.

Otomasyon mobil erişilebilirlikte neden sınırlı kalır?

Otomatik denetimler genellikle kod/DOM kalıplarını, ARIA kullanımını, renk kontrastını belirli eşiklerle ve bazı odak (focus) problemlerini tespit eder. Mobilde ise “erişilebilirlik”, yalnızca teknik etiketlerin varlığı değil; etkileşim akışının, jestlerin ve geri bildirimlerin doğru çalışmasıdır. Üstelik uygulama (native) ve mobil web, farklı erişilebilirlik API’leri ve bileşen davranışlarına sahiptir.

Bir örnek: Bir butonun erişilebilir adı var diye ekran okuyucu kullanıcısı o butonu doğru zamanda bulabiliyor mu? İşte otomasyonun yanıtlayamadığı soru bu.

Otomasyonun kaçırdığı kritik mobil a11y alanları

1) Ekran okuyucu ile gerçek etkileşim (jestler, rotor, keşfetme)

VoiceOver (iOS) ve TalkBack (Android) kullanıcıları, arayüzü “dokunarak keşfetme”, “sağa/sola kaydırarak ilerleme”, rotor/menülerle gezinme gibi yöntemlerle kullanır. Otomasyon; sıralamanın kullanıcı beklentisine uygun olup olmadığını, önemli kontrollerin gereksiz yere atlanıp atlanmadığını veya bir bileşenin yanlış rol/etiket nedeniyle “anlamsız” okunup okunmadığını çoğu zaman yakalayamaz.

• Okuma sırası görsel hiyerarşiyle uyuşuyor mu?
• Bileşenler doğru türde mi anons ediliyor (buton, sekme, anahtar, başlık)?
• Dinamik içerik değişince (liste güncelleme, filtreleme) kullanıcıya anlamlı bir anons geliyor mu?

Mobil web için daha detaylı kontrol adımları arıyorsanız, Android Erişilebilirlik Denetimi (Audit) rehberi iyi bir başlangıç çerçevesi sunar; iOS tarafında ise iOS Erişilebilirlik Denetimi yaklaşımını referans alabilirsiniz.

2) Dokunma hedefi boyutu ve “yanlış tıklama” riski

Mobilde erişilebilirlik, sadece “klavye ile gezilebilirlik” değildir. Dokunma hedeflerinin (ikon butonları, küçük linkler, kapatma çarpıları) yeterli boyutta olması; motor beceri farklılıkları olan kullanıcılar için kritik önemdedir. WCAG 2.2 ile birlikte hedef boyutu beklentisi daha görünür hale geldi (özellikle WCAG 2.2 Başarı Kriteri 2.5.8 Target Size (Minimum)). Otomasyon, pikselleri ölçse bile hedefin çevresindeki boşluklar, üst üste binen katmanlar ve gerçek kullanımda oluşan “yanlış dokunma” riskini her zaman doğru değerlendiremez.

• Küçük ikonlar (örn. favori, paylaş, kapat) tek elle kullanımda kolay mı?
• Kaydırılabilir alanlarda yanlışlıkla başka öğe tetikleniyor mu?
• Yapışkan (sticky) alt menü, içerik üzerindeki hedefleri kapatıyor mu?

3) Odak yönetimi ve modal/alt sayfa akışları

Otomasyon, odak halkası görünüyor mu veya tab sırası var mı gibi sinyalleri yakalasa da mobilde odak yönetimi daha karmaşık hale gelir: alt sayfalar, bottom sheet’ler, filtre çekmeceleri, tarih seçiciler, izin diyalogları… Ekran okuyucuda bir modal açıldığında odak gerçekten modal içine taşınıyor mu, arka plan “erişilemez” hale geliyor mu, kapatınca odak mantıklı yere dönüyor mu? Bu tür akışlar çoğunlukla manuel test gerektirir.

• Modal açılınca arka plan öğeleri hâlâ okunabiliyor mu? (Olmamalı.)
• Kapatma kontrolü erişilebilir adla sunuluyor mu?
• Kapatınca odak, kullanıcıyı bağlamdan koparmadan geri dönüyor mu?

4) Form hataları: yalnızca “kırmızı yazı” değil, anlaşılır ve anons edilen geri bildirim

Form doğrulama hataları otomasyonun sıkça “kısmen” yakaladığı bir alandır. Bir input’un aria-invalid değeri var diye kullanıcı hatayı anlıyor mu? Mobilde ekran küçük olduğundan hata mesajı klavyenin arkasında kalabilir; ekranda görünüyor olsa bile ekran okuyucu tarafından anons edilmeyebilir. WCAG açısından kritik olan, hatanın programatik olarak ilişkilendirilmesi ve kullanıcıya ne yapması gerektiğinin açıkça söylenmesidir (örn. 3.3.1, 3.3.3).

• Hata mesajı ilgili alanla ilişkilendirilmiş mi (label/description)?
• Hata çıktığında ekran okuyucu bunu otomatik duyuruyor mu?
• Hata metni “Geçersiz” yerine net yönlendirme veriyor mu?

5) Yakınlaştırma, metin boyutu ve yeniden akış (reflow) sorunları

Mobil kullanıcıların önemli bir kısmı yazı boyutunu artırır, ekranı yakınlaştırır veya sistem ölçeklendirmesi kullanır. Otomasyon çoğunlukla varsayılan metin boyutunda test yapar; halbuki gerçek dünyada metin büyüdüğünde butonlar taşabilir, satırlar üst üste binebilir, kritik bilgiler kesilebilir. Mobil web için 1.4.4 (Resize Text) ve 1.4.10 (Reflow) gibi kriterler; uygulamalar içinse dinamik yazı tipi (Dynamic Type) ve ölçeklenebilir arayüz pratikleri devreye girer.

• Metin %200 olduğunda CTA’lar ve fiyat bilgisi hâlâ okunabilir mi?
• Landscape/portrait geçişlerinde içerik kayboluyor mu?
• Sistem font büyütmede (iOS/Android) kırılmalar oluşuyor mu?

6) Renk/kontrast “geçti” ama hâlâ okunmuyor: durumlar, temalar, ışık koşulları

Kontrast denetleyicileri, belirli bir ekran görüntüsü veya CSS değeri üzerinden hesap yapar. Ancak mobilde karanlık mod, yüksek kontrast ayarları, güneş ışığında kullanım, ekran parlaklığı ve saydam katmanlar (overlay) okunabilirliği dramatik biçimde değiştirebilir. Ayrıca yalnızca renkle durum iletmek (aktif/pasif, hata/başarı) hâlâ yaygın bir problemdir.

• Karanlık modda ikonlar arka plana karışıyor mu?
• Hata yalnızca kırmızı çerçeveyle mi anlatılıyor?
• Grafikler/etiketler renk körlüğünde ayırt edilebilir mi?

7) Hareket, animasyon ve zamanlama: baş dönmesi ve kontrol kaybı

Mobil arayüzlerde animasyonlar sık kullanılır (kaydırmalı geçişler, otomatik dönen banner, “skeleton” yükleme). Otomasyon bu deneyimin vestibüler hassasiyeti olan kullanıcıları etkileyip etkilemediğini, hareket azaltma (reduce motion) ayarlarına saygı gösterilip gösterilmediğini veya zaman sınırlamalarının kullanıcıyı zorlayıp zorlamadığını anlamaz.

• “Hareketi azalt” açıkken animasyonlar duruyor/azalıyor mu?
• Otomatik kayan bileşenler durdurulabiliyor mu?
• Zaman aşımı kullanıcıyı habersiz mi yakalıyor?

Daha sağlam bir mobil a11y süreci: otomasyon + manuel + gerçek cihaz

En iyi sonuç, otomasyonu “erken uyarı sistemi” gibi konumlandırıp manuel testleri akış doğrulaması için kullanınca gelir. Pratik bir yaklaşım:

• CI/CD’de otomatik tarama: Mobil web için düzenli taramalarla bariz hataları erken yakalayın.
• Gerçek cihaz matrisi: En azından bir iPhone + bir Android cihazla, varsayılan ve büyütülmüş metin senaryolarını test edin.
• Ekran okuyucu senaryoları: Giriş, arama, sepete ekleme, ödeme gibi kritik akışları VoiceOver/TalkBack ile uçtan uca deneyin.
• Tasarım aşamasında kontrol: Dokunma hedefleri, hata metinleri ve durum göstergeleri tasarım sistemine kurallar olarak girsin.

Bu noktada, otomasyon tarafında tutarlı denetim ve izleme için Corpowid (corpowid.ai) gibi platformlar; düzenli erişilebilirlik taramaları, değişiklik sonrası risk takibi ve erişilebilirlik beyanı (statement) yönetimi gibi süreçleri daha yönetilebilir hale getirebilir. Yine de mobil a11y’de “etkileşim kalitesi” için manuel doğrulama katmanını planlamanız gerekir.

İş riski ve uyum: “otomasyon geçti” savunma değildir

Erişilebilirlik, sadece teknik bir kalite metriği değil; yasal ve itibari bir risktir. Otomasyon raporları, kullanıcı şikâyetleri veya hukuki süreçlerde tek başına yeterli kanıt sayılmayabilir. Bu konuda gerçek dünyadan bir örnek ve çıkarımlar için LA Community College’ın 242.500 Dolarlık Erişilebilirlik Kararı yazısı, “uyumluluk” beklentisinin pratikte ne anlama geldiğini iyi özetler.

Özellikle e-ticaret ve perakendede mobil akışlar (ürün keşfi, sepet, ödeme, mağaza bulucu) erişilebilir değilse, dönüşüm kaybı ve dışlanma etkisi hızla büyür. İlgili sektör bağlamı için E-ticaret Platformları için Dijital Erişilebilirlik ve Perakende Zincirleri için Dijital Erişilebilirlik içeriklerindeki kapsayıcı deneyim önerileri, mobil öncelikli ekipler için de uygulanabilir.

Sonuç: Otomasyon, mobil a11y’nin başlangıcıdır; tamamı değil

Otomasyon; eksik alt metinler, bazı kontrast sorunları, etiketlenmemiş form alanları gibi problemleri hızlıca görünür kılar. Ancak mobil erişilebilirlikte asıl farkı yaratan; ekran okuyucu jestleriyle akışın sorunsuz işlemesi, odak yönetimi, dokunma hedefleri, hata geri bildirimi, metin ölçeklenmesi ve tema/ayar çeşitliliğidir. Bu nedenle “otomasyon geçti” sonucunu, “kullanıcı için erişilebilir” sonucuna eşitlemeyin.

Sürecinizi otomasyon + manuel senaryo testleri + gerçek cihaz doğrulaması şeklinde kurduğunuzda hem WCAG uyumluluğuna yaklaşır hem de daha kapsayıcı bir mobil deneyim sunarsınız. Düzenli izleme ve raporlama tarafında Corpowid (corpowid.ai) ile otomatik denetimleri sürekli hale getirip, manuel test kapasitenizi en çok risk barındıran akışlara odaklayabilirsiniz.