Android Erişilebilirlik Denetimi (Audit): WCAG Uyumlu Mobil Deneyim İçin Kapsamlı Rehber

Android erişilebilirlik denetimi (accessibility audit), Android uygulamanızın veya mobil web sitenizin; ekran okuyucu, klavye/harici anahtar, büyütme, yüksek kontrast ve farklı dokunma hassasiyetleriyle kullanılabilir olup olmadığını sistematik olarak ölçme sürecidir. Amaç yalnızca “iyi niyetli” bir kullanıcı deneyimi yaratmak değil; aynı zamanda WCAG (Web Content Accessibility Guidelines) ilkeleriyle uyumlu, sürdürülebilir ve kanıtlanabilir bir erişilebilirlik standardı oluşturmaktır.

Bu rehberde Android’de erişilebilirlik denetimi nasıl yapılır, hangi araçlar kullanılır, en sık görülen hatalar nelerdir ve denetimi CI/CD süreçlerine nasıl taşıyabilirsiniz sorularını adım adım ele alıyoruz.

Android erişilebilirlik denetimi neden önemli?

Android ekosistemi; farklı ekran boyutları, üretici arayüzleri (One UI vb.), çok çeşitli giriş yöntemleri ve farklı kullanıcı ihtiyaçlarıyla heterojendir. Bu nedenle bir özelliğin “benim telefonumda çalışması”, erişilebilir olduğu anlamına gelmez.

• Hukuki ve kurumsal riskler: Dijital erişilebilirlik davaları ve yaptırımlar, mobil deneyimleri de kapsayacak şekilde genişliyor. Örnek vakalara dair dersleri Winn-Dixie erişilebilirlik davası ve LA Community College karar analizi üzerinden inceleyebilirsiniz.
• Ürün kalitesi ve dönüşüm: Net odak sırası, yeterli kontrast ve anlaşılır hata mesajları; herkes için kullanılabilirliği artırır. Bu yaklaşımın e-ticaretteki etkilerini e-ticaret platformlarında dijital erişilebilirlik yazısında görebilirsiniz.
• Tedarik ve kanıt ihtiyacı: Özellikle kamu/kurumsal alımlarda erişilebilirlik kanıtı istenebilir. Bu bağlamda Section 508 VPAT kavramı önemli bir referanstır.

Android’de WCAG nasıl uygulanır?

WCAG doğrudan “web” için yazılmış görünse de, Android uygulamalarında da aynı ilkeleri (Algılanabilir, Kullanılabilir, Anlaşılabilir, Sağlam) pratikte uygulamak mümkündür. Android tarafında bu ilkeler; TalkBack ile okunabilirlik, odak yönetimi, dokunma hedefleri, hareket/animasyon tercihleri, renk-kontrast ve içerik hiyerarşisi gibi somut test maddelerine dönüşür.

iOS tarafı için ayrı bir kontrol çerçevesi gerekiyorsa, yaklaşımı kıyaslamak adına iOS Erişilebilirlik Denetimi rehberi de faydalı olacaktır.

Denetime başlamadan: Kapsam ve senaryoları netleştirin

1) Neyi denetliyorsunuz: native uygulama mı, mobil web mi?

Native Android uygulamalarında (Compose veya XML) erişilebilirlik semantiklerinin doğru verilmesi gerekir. Mobil web’de ise HTML semantik, ARIA kullanımı ve tarayıcı/ekran okuyucu etkileşimi öne çıkar. Denetim çıktılarınızda bu ayrımı açıkça belirtin.

2) Kritik kullanıcı akışlarını seçin

Her ekranı tek tek denetlemek yerine, önce “iş değeri yüksek” akışları seçmek daha hızlı sonuç verir: kayıt/oturum açma, arama, ödeme, form gönderimi, müşteri hizmetleri, bildirim izinleri vb.

3) Başarı kriterlerini belirleyin

Kurumsal hedefiniz genellikle WCAG 2.1 AA (veya 2.2 AA) olur. Denetimde her bulguyu ilgili başarı kriteriyle ilişkilendirmek; önceliklendirme ve raporlama kalitesini ciddi ölçüde artırır.

Android erişilebilirlik denetiminde kullanılacak araçlar

Android Accessibility Scanner

Google’ın Accessibility Scanner aracı, uygulama ekranlarındaki temel sorunları (küçük dokunma hedefleri, düşük kontrast, içerik etiketleri vb.) hızlıca işaretler. “Hızlı tarama” için iyi bir başlangıçtır; ancak tek başına yeterli değildir.

TalkBack ile manuel test

Asıl kaliteyi belirleyen test, TalkBack ile gerçek gezinme deneyimidir. Denetimi şu modlarla yapın:

• Dokunarak keşfetme: Ekrana dokununca doğru öğe okunuyor mu?
• Kaydırma hareketleri: Sağ/sol kaydırma ile odak mantıklı sırada ilerliyor mu?
• Eylemler: “Çift dokun” ile aktivasyon, özel eylemler ve menüler çalışıyor mu?

Geliştirici/QA için ek kontroller

• Kontrast ölçümü: Metin/arka plan kontrastı (özellikle küçük metinlerde) WCAG eşiklerini karşılıyor mu?
• Dinamik yazı boyutu: Sistem yazı boyutu büyütüldüğünde kırılma, üst üste binme var mı?
• Ekran döndürme ve yeniden akış: Yatay/dikey geçişlerde içerik kaybı yaşanıyor mu?
• Animasyon/azaltılmış hareket: Hareket hassasiyeti olan kullanıcılar için gereksiz animasyonlar kontrol ediliyor mu?

Eğer denetimleri düzenli ve izlenebilir şekilde sürdürmek istiyorsanız, web tarafında otomatik tarama ve izleme yaklaşımı fayda sağlar. Bu noktada Corpowid (corpowid.ai), sitenizdeki erişilebilirlik sorunlarını periyodik olarak tespit edip izleyerek ekiplerin aynı hataları tekrar üretmesini azaltmaya yardımcı olabilir.

En sık bulunan Android erişilebilirlik sorunları (ve nasıl test edilir)

1) Eksik veya anlamsız içerik etiketleri (Content Description/Label)

İkon butonlar (arama, geri, kapat, favori) TalkBack tarafından “button” gibi anlamsız okunuyorsa kullanıcı ne yapacağını bilemez. Her etkileşimli öğenin erişilebilir adı olmalı.

• Test: TalkBack ile öğeye gelin; okunan ad, amaçla uyumlu mu?
• İpucu: “Daha fazla” gibi belirsiz metinler yerine bağlama özel adlar kullanın (ör. “Filtreleri aç”).

2) Odak sırası ve odak tuzağı

Modal açıldığında odak modale taşınmıyorsa veya modal kapanınca odak mantıksız bir yere gidiyorsa, kullanıcı akışı kopar. Ayrıca bazı bileşenler odak “tuzağı” yaratabilir.

• Test: Sağ/sol kaydırma ile tüm öğeleri dolaşın; sıra görsel akışla tutarlı mı?
• Test: Açılır menü/modal içinde dolaşabiliyor ve çıkabiliyor musunuz?

3) Dokunma hedefleri çok küçük

Özellikle liste içi ikonlar ve yakın duran butonlar, motor beceri farklılıklarında kritik engel oluşturur.

• Test: Küçük ikonlara hatasız dokunabiliyor musunuz?
• İpucu: Dokunma alanını büyütmek, görsel boyutu büyütmek zorunda değildir.

4) Renk kontrastı ve yalnızca renkle anlatım

Hata durumunun sadece kırmızı renkle belirtilmesi veya düşük kontrastlı metinler, hem düşük görme hem de renk körlüğü senaryolarında sorun yaratır.

• Test: Kontrast oranlarını ölçün; küçük metinlerde eşiklerin altına düşmeyin.
• Test: Hata/success durumları ikon, metin ve/veya açıklama ile destekleniyor mu?

5) Form alanları: Hata mesajı, ipucu ve odak

Form doğrulama hataları TalkBack’e okunmuyorsa kullanıcı “neden ilerleyemediğini” anlayamaz. Ayrıca placeholder’ın etiket yerine kullanılması yaygın bir hatadır.

• Test: Hata oluştuğunda odak hata özetine/alanına gidiyor mu?
• Test: Hata mesajı programatik olarak ilişkilendirilmiş mi ve okunuyor mu?

Raporlama: Bulguları nasıl yazmalı?

İyi bir erişilebilirlik denetim raporu; “ne yanlış”tan fazlasını içerir. Her bulgu için şu alanlar kaliteyi artırır:

• Özet: Sorun ne, kullanıcıyı nasıl etkiliyor?
• Konum: Ekran adı, URL (mobil web), bileşen adı, akış adımı.
• WCAG eşlemesi: İlgili başarı kriteri (ör. 1.4.3 Kontrast, 2.4.3 Odak Sırası).
• Yeniden üretim adımları: TalkBack açıkken adım adım.
• Beklenen/gerçek sonuç: Net karşılaştırma.
• Önerilen düzeltme: Tasarım ve geliştirme için uygulanabilir çözüm.
• Öncelik: Etki (kritik/orta/düşük) ve sıklık.

Denetimi sürdürülebilir kılma: İzleme ve süreç entegrasyonu

Tek seferlik audit, erişilebilirliğin yalnızca fotoğrafını çeker. Gerçek kazanım; yeni sürümlerde erişilebilirlik regresyonlarını yakalamaktır. Şu pratikler önerilir:

• Tasarım aşamasında kontrol: Renk, tipografi, bileşen kütüphanesi ve durumlar (hata/disabled/loading) erişilebilirlik açısından standardize edilmeli.
• QA kontrol listesi: Her release için kısa bir TalkBack ve kontrast kontrolü.
• Web içerikleri için otomatik izleme: Mobil web sayfalarında yeni içerik/hata artışlarını düzenli takip edin. Corpowid (corpowid.ai) gibi platformlar, otomatik denetimler ve izleme ile ekiplerin tekrar eden sorunları daha erken yakalamasına yardımcı olabilir.

Sonuç

Android erişilebilirlik denetimi; TalkBack ile gerçek kullanıcı davranışlarını simüle eden manuel testleri, otomatik taramalarla destekleyen ve WCAG başarı kriterleriyle raporlanan disiplinli bir süreçtir. Doğru kapsam, doğru araçlar ve iyi raporlama ile hem kullanıcı deneyimini güçlendirir hem de uyumluluk risklerini azaltırsınız. En iyi sonuç için denetimi tek seferlik bir “kontrol” değil, ürün geliştirme yaşam döngüsünün kalıcı bir parçası olarak konumlandırın.