Mobil Erişilebilirlik: WCAG'ı iOS ve Android'e Uygulamak

Mobil erişilebilirlik mühendislik disiplini olarak ele alındığında iOS ve Android arasında görünürdeki farklar hızla kaybolur: her ikisi de aynı temel standarda, WCAG'a, yaslanır. Bu rehber WCAG 2.2'nin somut başarı ölçütlerini iOS'ta VoiceOver ve Android'de TalkBack üzerinden nasıl karşıladığını, dokunma hedefi ve kontrast gibi ölçülebilir kriterleri, otomatik+manuel test protokolünü ve Avrupa'daki yasal zorunluluğu tek yerde topluyor.

💡 Pro Tip: Erişilebilirliği son sprint'e bırakma — dokunma hedefi ve odak sırası, UI bileşenleri tasarım aşamasında doğru kurgulanmazsa sonradan yama ile değil yeniden yazımla düzelir.

İçindekiler

• WCAG'ın mobil karşılığı: hangi kriter neye denk geliyor
• Neden WCAG, neden mobilde de geçerli
• Ekran okuyucu: VoiceOver ve TalkBack semantiği
• Pratik fark: rotor ve menü
• Dokunma hedefi, odak sırası ve gezinme
• Odak sırası neden ayrı bir mesele
• Kontrast, dinamik yazı tipi ve reduced motion
• Form ve hata mesajlarında erişilebilirlik
• Otomatik test: axe-core, Accessibility Scanner ve Accessibility Inspector
• Otomatik testin sınırları
• Manuel test protokolü
• Yasal çerçeve: WCAG'dan EAA'ya
• SSS
• WCAG kriterleri mobil uygulamaya nasıl uygulanır?
• Dokunma hedefi minimum kaç px olmalı?
• VoiceOver ve TalkBack testi nasıl yapılır?
• Erişilebilirlik yasal zorunluluk mu?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

WCAG'ın mobil karşılığı: hangi kriter neye denk geliyor

WCAG (Web Content Accessibility Guidelines), W3C'nin resmi Recommendation belgesi olarak yayımlanır ve ISO/IEC 40500 standardı olarak da kabul edilir. WCAG 2.2 ilk kez 5 Ekim 2023'te Recommendation olarak yayımlandı; 12 Aralık 2024'te güncellenmiş Recommendation yayımlandı (W3C). "Web" adını taşısa da W3C'nin kendi tanıtım sayfası, küçük ekranlı telefon ve akıllı saat kullananların da erişilebilirlikten fayda gördüğünü belirtir; WCAG'ın kendisi ise platform-agnostik yazıldığı için mobil native uygulamalara da doğrudan uygulanabilir.

Mobil arayüzler için en doğrudan karşılık bulan kriterler şunlar:

Bu yedi kriterin beşi (2.4.11, 2.4.13, 2.5.7, 2.5.8, 3.2.6) WCAG 2.2 ile gelen dokuz yeni başarı ölçütünün parçası; ikisi (1.4.3, 2.3.3) önceki sürümlerden devralındı. Uygulamanı bu tabloya göre denetlemek, "erişilebilirlik" gibi muğlak bir hedefi somut, test edilebilir kontrol maddelerine indirger.

Neden WCAG, neden mobilde de geçerli

WCAG'ın kendisi platform-agnostik yazılmıştır: "içerik" ve "kullanıcı arayüzü bileşeni" gibi terimler hem web hem native uygulamalara uygulanabilir şekilde tanımlanır. W3C'nin resmi konumu net: web erişilebilirliği birçok durumda yasal bir zorunluluktur — ve bu zorunluluk, aşağıda ele alacağımız Avrupa Erişilebilirlik Yasası ile native mobil uygulamalara da taşınıyor.

Ekran okuyucu: VoiceOver ve TalkBack semantiği

İki platformun ekran okuyucusu da dokunmatik jestlerle çalışır ama gezinme mantığı birebir örtüşmez.

Apple'ın resmi destek dokümanına göre VoiceOver "hareket tabanlı bir ekran okuyucu"dur ve kullanıcı ekranı göremese bile iPhone'u kullanmasına imkân verir. Yeni bir ekrana geçildiğinde VoiceOver önce bir ses çalar, sonra ekrandaki ilk öğeyi seçip adını okur — yani her ekran geçişinde otomatik bir "giriş anonsu" vardır.

Google'ın TalkBack sayfası ise cihazı "gözler kapalı" kontrol etmeyi merkeze koyar. TalkBack 9.1'den (Mart 2021) itibaren çok parmaklı jestler destekleniyor; bu, tek parmak kaydırma ile öğe-öğe gezinmenin yanına global ve yerel bağlam menülerine hızlı erişim ekledi.

Pratik fark: rotor ve menü

VoiceOver kullanıcıları "rotor" adı verilen dairesel bir kontrolle gezinme modunu (başlıklar, bağlantılar, form alanları) değiştirir. TalkBack'te bu işlevi yerel/global bağlam menüleri üstlenir. Bu, aynı semantik bilgiyi (başlık, buton, bağlantı) doğru şekilde işaretlemenin neden iki platformda da aynı derecede kritik olduğunu açıklar: rol bilgisi yanlışsa, kullanıcı doğru gezinme moduna geçemez.

1// SwiftUI: bir butona anlamlı, kısa bir erişilebilirlik etiketi vermek
2Button(action: addToCart) {
3    Image(systemName: "cart.badge.plus")
4}
5.accessibilityLabel("Sepete ekle")
6.accessibilityHint("Ürünü sepete ekler")

1// Jetpack Compose: contentDescription'da SONUCU anlat, görsel detayı değil
2// (developer.android.com/guide/topics/ui/accessibility/apps önerisi:
3//  "Submit" yaz, "Submit button" yazma — rolü sistem zaten okur)
4IconButton(onClick = { addToCart() }) {
5    Icon(
6        imageVector = Icons.Filled.AddShoppingCart,
7        contentDescription = "Sepete ekle"
8    )
9}

Metin bileşenlerine (düz Text composable'lar gibi) ayrı bir contentDescription vermen gerekmez — TalkBack görünen metni zaten otomatik okur; resmi Android dokümanı bu ilkeyi açıkça belirtir. iOS'ta VoiceOver derinliğine inmek isteyenler için ayrı bir kaynak var: mevcut iOS Accessibility rehberi VoiceOver ve Dynamic Type'ı satır satır işliyor, bu yazı onu tekrarlamak yerine iki-platformlu WCAG haritasına odaklanıyor.

Dokunma hedefi, odak sırası ve gezinme

Dokunma hedefi büyüklüğü, WCAG 2.2 SC 2.5.8 ile ölçülebilir bir asgariye bağlandı: işaretçi girdileri için hedefler en az 24×24 CSS piksel olmalı (bitişik hedefler, satır-içi metin bağlantıları gibi belirli istisnalar dışında).

Android tarafında platform kılavuzu bu asgarinin üzerine çıkıyor. Resmi Android geliştirici dokümanı şunu söylüyor: her etkileşimli UI öğesinin odaklanılabilir alanı en az 48×48dp olmalı — "büyüğü daha iyidir" notuyla. Yani Android'in kendi Material Design önerisi, WCAG'ın 24×24 CSS piksel asgarisinin belirgin şekilde üstünde bir hedef koyuyor.

Apple'ın kendi sayısal eşiğini bu tabloda kaynaksız yazmıyoruz; iki platformda ortak ve güvenli asgari olarak Android'in 48×48dp önerisini kullan.

Odak sırası neden ayrı bir mesele

Dokunma hedefi "büyüklük" sorusuysa, odak sırası "sıra" sorusudur. WCAG 2.2'nin SC 2.4.11 (Focus Not Obscured, AA) kriteri, klavye veya harici anahtar kontrolüyle gezinen kullanıcılar için odaklanan öğenin yazar içeriğiyle tamamen gizlenmemesini şart koşuyor; SC 2.4.13 (Focus Appearance, AAA) ise odak göstergesinin daha da belirgin ve ayırt edilebilir olmasını isteyen, daha ileri bir hedef. Mobilde bu, özellikle sabit (sticky) header/footer'lı ekranlarda ve modal diyaloglarda test edilmesi gereken bir senaryo: odak modalın arkasında kalan bir öğeye "kaçabiliyor" mu?

Kontrast, dinamik yazı tipi ve reduced motion

Kontrast ve hareket kriterleri platform bağımsızdır, bu yüzden hem iOS hem Android için ortak zemin oluşturur.

WCAG 2.2 SC 1.4.3, normal metin için en az 4.5:1, büyük metin için en az 3:1 kontrast oranı şartı koyar. Bu formül WCAG 2.0'dan (2008) beri değişmedi ve 2.2'de aynen korunuyor. Kontrast oranını elle hesaplamak yerine kodda doğrulamak, tasarım tokenlarının drift etmesini engeller:

1// WCAG kontrast oranı hesaplama — SC 1.4.3 formülü
2function relativeLuminance([r, g, b]) {
3  const toLinear = (c) => {
4    const s = c / 255;
5    return s <= 0.03928 ? s / 12.92 : Math.pow((s + 0.055) / 1.055, 2.4);
6  };
7  const [R, G, B] = [r, g, b].map(toLinear);
8  return 0.2126 * R + 0.7152 * G + 0.0722 * B;
9}
10 
11function contrastRatio(hex1, hex2) {
12  const parse = (hex) =>
13    [1, 3, 5].map((i) => parseInt(hex.slice(i, i + 2), 16));
14  const L1 = relativeLuminance(parse(hex1));
15  const L2 = relativeLuminance(parse(hex2));
16  const [lighter, darker] = L1 > L2 ? [L1, L2] : [L2, L1];
17  return (lighter + 0.05) / (darker + 0.05);
18}
19 
20console.log(contrastRatio("#333333", "#FFFFFF").toFixed(2));
21// -> 12.63  (WCAG 4.5:1 asgarisini rahatça geçiyor)

Hareket tarafında WCAG 2.1'den (2018) beri geçerli olan SC 2.3.3 Animation from Interactions (AAA), etkileşimle tetiklenen hareket animasyonunun -gerekli olmadığı sürece- kapatılabilir olmasını istiyor. Bu, iOS'un "Hareketi Azalt" ve Android'in "Hareketi kaldır" gibi sistem düzeyi tercihlerine saygı duyan bir uygulama tasarımı anlamına gelir: geçiş animasyonların süresini sıfıra indirmek veya alternatif, hareketsiz bir geçişe düşmek gibi.

Form ve hata mesajlarında erişilebilirlik

Form hataları, ekran okuyucu kullanıcıları için en sık kaybolan bilgi türüdür — hata mesajı yalnızca görsel olarak (kırmızı çerçeve, kenar ikonu) gösterilirse, VoiceOver veya TalkBack kullanan biri hiç fark etmez. WCAG 2.2'nin SC 3.2.6 Consistent Help kriteri doğrudan form hatalarını hedeflemese de, aynı ilkeyi genelleştirir: yardım mekanizmaları (bu durumda hata açıklaması ve düzeltme önerisi) sayfalar arasında tutarlı bir konumda ve tutarlı bir şekilde sunulmalı.

• Etiket bağlama: her form alanı, görünür bir etiketle programatik olarak ilişkilendirilmeli (placeholder tek başına etiket yerine geçmez).
• Hata anonsu: hata metni yalnızca renkle değil, metin olarak da sunulmalı ve odak hata alanına taşınmalı.
• Alan grupları: ilişkili alanlar (örn. adres satırları) mantıksal bir grup olarak okunmalı, tek tek kopuk cümleler olarak değil.
• Zorunlu alan işareti: "zorunlu" bilgisi görsel yıldız kadar, ekran okuyucuya da metin olarak ulaşmalı.

Aynı ilke SwiftUI tarafında da geçerli: bir metin alanına yalnızca placeholder vermek yeterli değildir, alanın kendisi ve varsa hata durumu birer erişilebilirlik özelliği olarak tanımlanmalı.

1// SwiftUI: form alanına programatik etiket + hata durumu anonsu
2TextField("", text: $email)
3    .accessibilityLabel("E-posta adresi")
4    .accessibilityValue(emailError ?? "")
5    .accessibilityHint(emailError != nil ? "Hata: \(emailError!)" : "")

Buradaki accessibilityValue, alanın mevcut durumunu (geçerli/hatalı) ekran okuyucuya değer olarak iletir; accessibilityHint ise kullanıcıyı düzeltmeye yönlendiren kısa bir ipucu ekler. Hata metnini yalnızca görünür bir Text bileşeniyle göstermek, ekran okuyucu odak sırası o Texte denk gelmediği sürece anons edilmeyebilir — bu yüzden hatayı doğrudan ilgili alanın erişilebilirlik değerine bağlamak daha güvenilir.

Otomatik test: axe-core, Accessibility Scanner ve Accessibility Inspector

Otomatik test, erişilebilirlik hatalarının büyük bir kısmını (kontrast, eksik etiket, semantik rol) insan müdahalesi olmadan yakalar — ama manuel testin yerini tutmaz.

axe-core (Deque Labs), kendini "web siteleri ve diğer HTML tabanlı kullanıcı arayüzleri için bir erişilebilirlik test motoru" olarak tanımlıyor ve mevcut test ortamlarına sorunsuz entegre olacak şekilde tasarlandığını belirtiyor.

1// axe-core: sayfa/ekran üzerinde temel tarama
2import axe from "axe-core";
3 
4axe.run(document, { runOnly: ["wcag2a", "wcag2aa"] }).then((results) => {
5  console.log(`${results.violations.length} ihlal bulundu`);
6  results.violations.forEach((v) => console.log(v.id, "-", v.help));
7});

Android tarafında resmi test dokümanı dört yaklaşımı birlikte öneriyor: manuel test, analiz araçları (Accessibility Scanner), otomatik UI testleri ve kullanıcı testi. iOS'ta ise Xcode'a gömülü Accessibility Inspector, canlı simülatör/cihaz üzerinde etiket ve kontrast denetimi yapar.

CI'da TalkBack'i uçtan uca senaryolarda otomatik açıp kapatmak için ADB kullanılabilir:

1# CI cihazında TalkBack'i etkinleştir / devre dışı bırak
2adb shell settings put secure enabled_accessibility_services \
3  com.google.android.marvin.talkback/com.google.android.marvin.talkback.TalkBackService
4adb shell settings put secure accessibility_enabled 1
5 
6# testten sonra kapat
7adb shell settings put secure accessibility_enabled 0

Bu komut gerçek cihaz farklılıklarına duyarlı olabilir; kararlı bir sonuç için CI'daki otomasyonu gerçek cihazda manuel bir doğrulama turuyla desteklemek gerekir.

Otomatik testin sınırları

axe-core, Accessibility Scanner ve Accessibility Inspector'ın üçü de statik semantik hataları (eksik etiket, düşük kontrast, yanlış rol) güvenilir şekilde yakalar. Ama hiçbiri şu sorulara cevap veremez: kullanıcı bu akışı gerçekten ekran okuyucuyla tamamlayabiliyor mu, odak sırası mantıklı mı, dinamik bir bildirim doğru anda anons ediliyor mu? Bu üç soru, yapısı gereği yalnızca bir insanın ekran okuyucuyu açıp uçtan uca kullanmasıyla yanıtlanabilir — otomatik araçları "ilk filtre", manuel testi "kabul kriteri" olarak konumlandırmak bu yüzden önemli.

Manuel test protokolü

Otomatik araçlar semantik hataları yakalar ama "bu akış gerçekten kullanılabilir mi" sorusunu yanıtlayamaz. Manuel protokolün iskeleti iki platformun kendi resmi ekran okuyucu akışına dayanır:

1. Ayarlar üzerinden aç: iOS'ta Ayarlar > Erişilebilirlik > VoiceOver; Android'de Ayarlar > Erişilebilirlik > TalkBack. İkisi de öğretici bir ilk-açılış akışı sunar — bu akışı bizzat tamamlamak, kendi jest setine aşina olmak için gerekli.
2. Yalnız ekran okuyucuyla gezin: ekranı kapatmadan (görsel geri bildirimi izleyerek) yalnızca parmak kaydırma ve çift dokunuşla tüm birincil akışı (ör. formu doldurup gönderme) tamamla.
3. Odak sırasını doğrula: her ekranda odağın mantıksal sırayla (üstten alta, soldan sağa) ilerlediğini, hiçbir etkileşimli öğenin atlanmadığını kontrol et.
4. Dinamik içerik anonsunu kontrol et: bir hata mesajı veya yükleniyor durumu ekrana geldiğinde ekran okuyucunun bunu otomatik anons edip etmediğini doğrula.
5. Jest çakışmasını test et: uygulamaya özel kaydırma/sürükleme jestlerinin, ekran okuyucunun kendi jestleriyle (örn. sağa-sola kaydırarak öğe değiştirme) çakışıp çakışmadığına bak.

Yasal çerçeve: WCAG'dan EAA'ya

W3C'nin kendi erişilebilirlik giriş sayfası net bir cümleyle başlıyor: web erişilebilirliği birçok durumda yasal bir zorunluluktur. Avrupa'da bu ilke somut bir tarihe bağlandı: Avrupa Erişilebilirlik Yasası (European Accessibility Act, EAA) kapsamında üye devletler, direktifi 2022 Haziran'ına kadar kendi ulusal hukuklarına aktarmakla yükümlüydü. Avrupa Komisyonu'nun resmi EAA sayfası, kapsamın bilgisayarlar ve işletim sistemleri, akıllı telefonlar, e-kitaplar ve e-ticareti içerdiğini açıkça listeliyor. EAA'nın temelini oluşturan 2019/882 sayılı direktif, tedbirlerin 28 Haziran 2025'ten itibaren uygulanacağını da sabitliyor (EUR-Lex, Madde 31); takvimi belli, bağlayıcı bir yükümlülük.

• Transpozisyon: üye devletler EAA'yı Haziran 2022'ye kadar ulusal hukuka aktarmakla yükümlüydü.
• Kapsam: bilgisayar/işletim sistemi, akıllı telefon, bankacılık hizmetleri, e-ticaret, e-kitap dahil geniş bir ürün/hizmet listesi.
• İlişki: EAA'nın teknik gereksinimleri WCAG'daki başarı ölçütleriyle büyük ölçüde örtüşür — yani bu yazıdaki tablo, hem "iyi pratik" hem "yasal kontrol listesi" olarak okunabilir.

SSS

WCAG kriterleri mobil uygulamaya nasıl uygulanır?

WCAG platform-agnostik yazıldığı için doğrudan uygulanır: SC 2.5.8 dokunma hedefi büyüklüğünü, SC 1.4.3 metin kontrastını, SC 2.4.11/2.4.13 odak görünürlüğünü, SC 2.5.7 sürükleme alternatifini ve SC 3.2.6 tutarlı yardımı native iOS/Android bileşenlerine birebir eşleyebilirsin — yukarıdaki tablo bu eşlemeyi özetliyor.

Dokunma hedefi minimum kaç px olmalı?

WCAG 2.2 SC 2.5.8'e göre işaretçi hedefleri en az 24×24 CSS piksel olmalı (istisnalarla). Android'in kendi resmi geliştirici dokümanı bunun üzerine çıkıp en az 48×48dp öneriyor; pratikte bu değer iki platformda ortak, güvenli bir hedef olarak kullanılabilir.

VoiceOver ve TalkBack testi nasıl yapılır?

İkisi de cihaz ayarlarından açılır ve kendi öğretici akışıyla başlar. Manuel test için ekranı görsel olarak takip ederken yalnızca ekran okuyucunun jestleriyle (kaydırma, çift dokunuş) birincil akışı baştan sona tamamlamak, odak sırasının mantıklı ilerlediğini ve dinamik içerik değişimlerinin anons edildiğini doğrulamak gerekir.

Erişilebilirlik yasal zorunluluk mu?

W3C'nin kendi ifadesiyle evet — web erişilebilirliği birçok durumda yasal bir zorunluluktur. Avrupa'da bu, Avrupa Erişilebilirlik Yasası (EAA) ile somutlaşıyor: üye devletler direktifi Haziran 2022'ye kadar ulusal hukuka aktarmakla yükümlüydü, tedbirler ise 28 Haziran 2025'ten itibaren uygulanıyor; kapsam akıllı telefonlar ile e-ticareti içeriyor.

Güncelleme (Eylül 2026)

Bu makalenin gövdesi 5 Mart 2025 tarihindeki sürüm ve araç bilgisine dayanıyor. O tarihten sonra değişenler:

EAA yükümlülüğü fiilen başladı. Gövdede yer alan 28 Haziran 2025 tarihi geldi ve direktifin öngördüğü tedbirler bu tarihten itibaren fiilen uygulanmaya başladı (akıllı telefonlar, bilgisayar/işletim sistemleri, bankacılık, e-ticaret dahil). AB'de faaliyet gösteren veya AB kullanıcısına hizmet veren mobil uygulamalar için erişilebilirlik artık isteğe bağlı bir iyileştirme değil, aktif bir yükümlülük.

WCAG hâlâ 2.2 — büyük bir versiyon kırılması yok. W3C'nin güncel Recommendation'ı hâlâ WCAG 2.2 (12 Aralık 2024 tarihli güncellenmiş Recommendation); makaledeki kriter tablosu güncelliğini koruyor.

Platformlar sürüm yükseltti. Apple'ın platform adlandırması iOS 26'nın ardından iOS 27'ye ulaştı ve VoiceOver bu sürümlerde çalışmaya devam ediyor. Android tarafında AOSP resmi sürüm tablosu Android 17'yi (API level 37) listeliyor ve TalkBack güncel sürümüyle (17.0) kullanılabiliyor. Bu sürüm yükseltmeleri WCAG-mobil haritalamasını (dokunma hedefi, kontrast, odak sırası) değiştirmedi; makaledeki eşleme güncelliğini koruyor.

Sonuç

Mobil erişilebilirlik, iOS ve Android'i ayrı ayrı öğrenilmesi gereken iki dünya olarak değil, WCAG 2.2'nin ortak kriter setinin iki farklı native uygulaması olarak ele alındığında yönetilebilir hale gelir. Dokunma hedefi, kontrast, odak sırası ve otomatik test — bu dördü CI'a ve PR şablonuna gömdüğünde, ekran okuyucu testini "ekstra iş" değil normal kabul kriteri haline getirmiş olursun.

Konuyu derinleştirmek için: iOS'a özel VoiceOver ve Dynamic Type detayları için iOS Accessibility rehberi, cross-platform mimari kararların erişilebilirlik dahil production etkilerini görmek için Flutter vs SwiftUI production karşılaştırması ve Compose Multiplatform production rehberi, test kültürünü genişletmek için Flutter test rehberi, ve Android tarafında performans+erişilebilirlik dengesini görmek için Jetpack Compose 1.7 performance rehberi faydalı olacaktır.

Kaynaklar

• W3C WAI — Accessibility Fundamentals — WCAG'ın ISO/IEC 40500 statüsü, yasal zorunluluk ve mobil kapsam ifadesi
• W3C — WCAG 2.2 Recommendation — bu yazıda kullanılan tüm başarı ölçütlerinin birincil metni
• Android Developers — Make apps more accessible — dokunma hedefi, contentDescription önerileri
• Android Developers — Test your app's accessibility — Accessibility Scanner ve otomatik kontrol önerisi
• Apple Support — VoiceOver'ı aç ve pratik yap — VoiceOver'ın gezinme/anons davranışı
• Google — TalkBack erişilebilirlik hizmeti — TalkBack jest geçmişi ve sürüm notu
• Deque Labs — axe-core (GitHub) — otomatik erişilebilirlik test motoru
• Avrupa Komisyonu — European Accessibility Act — EAA kapsamı ve transpozisyon takvimi
• EUR-Lex — Directive (EU) 2019/882 (ELI) — EAA'nın birincil metni, Madde 31: tedbirlerin 28 Haziran 2025'ten itibaren uygulanacağı
• AOSP — Codenames, tags, and build numbers — Android 17 / API level 37 satırı
• Google Play — Android Accessibility Suite (TalkBack) — "What's new: TalkBack 17.0"