Avrupa Erişilebilirlik Yasası ve Mobil Uygulamalar

Avrupa Erişilebilirlik Yasası (European Accessibility Act - EAA), 28 Haziran 2025'ten itibaren bankacılık, e-ticaret, ulaşım ve e-kitap gibi alanlardaki mobil uygulamaları doğrudan ilgilendiren bir AB direktifi. Uygulamanı Avrupa pazarında tutuyorsan ya da tutmayı planlıyorsan, bu yazıda yasanın kapsamını, hangi uygulamaların istisna kapsamına girebildiğini ve iOS/Android tarafında teknik olarak ne yapman gerektiğini adım adım bulacaksın.

💡 Pro Tip: Uyum çalışmasına başlamadan önce mevcut uygulamanı gerçek bir ekran okuyucuyla (VoiceOver veya TalkBack) uçtan uca gezerek dene — kağıt üzerinde "kontrast yeterli" görünen bir ekranda bile, gerçek kullanımda farklı sorunlarla karşılaşabilirsin.

İçindekiler

• Yasanın Kapsamı ve 28 Haziran 2025 Tarihi
• Kapsam Dışı Kalabilen Uygulamalar
• Teknik Karşılıklar: WCAG Kriterlerinin Mobildeki Hâli
• iOS Tarafı: Erişilebilirlik Yaklaşımı
• Android Tarafı: TalkBack ve Teknik Karşılıklar
• Otomatik Denetim + Manuel Test Protokolü
• Uyum Dosyası ve Kanıt Saklama
• SSS
• Avrupa Erişilebilirlik Yasası mobil uygulamaları kapsıyor mu?
• Uygulama tarihi ne zaman?
• Uyum için teknik olarak ne yapmalıyım?
• Uygulamam küçük bir ekip tarafından geliştiriliyorsa muaf mıyım?
• Sadece App Store/Play Store'da mı, yoksa web sürümünde de mi uyum gerekiyor?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

Yasanın Kapsamı ve 28 Haziran 2025 Tarihi

Avrupa Erişilebilirlik Yasası, Avrupa Komisyonu'nun resmi ifadesiyle "farklı Üye Devlet kurallarının yarattığı engelleri kaldırarak erişilebilir ürün ve hizmetler için iç pazarın işleyişini iyileştirmeyi" amaçlıyor. Yasa 2019'da kabul edildi, Üye Devletler direktifi Haziran 2022'ye kadar ulusal hukuka aktarmakla yükümlüydü ve asıl uygulama (compliance) tarihi 28 Haziran 2025 olarak belirlendi.

Komisyonun kapsam listesinde bilgisayarlar ve işletim sistemleri, akıllı telefonlar, ATM/biletleme/check-in makineleri, TV ekipmanı, telefon hizmetleri, bankacılık hizmetleri, e-kitaplar ve e-ticaret açıkça yer alıyor. Direktifin e-ticaret hizmeti tanımı (Md. 3(30)) bu hizmetleri "uzaktan, web siteleri ve mobil cihaz tabanlı hizmetler aracılığıyla, elektronik yolla" sunulan hizmetler olarak tarif ediyor; Md. 2(4) ise istisnaları sayarken doğrudan "web sitelerinin ve mobil uygulamaların içeriği" ifadesini kullanıyor. Yani belirleyici olan cihazın türü değil, uygulamanın hangi hizmeti sunduğu — özellikle bankacılık, e-ticaret ve e-kitap uygulamaları bu tanımın doğrudan kapsamında.

Komisyon, direktifin eksiksiz ve doğru şekilde aktarılıp uygulandığını izliyor. Bunun yanında, uygulama ve aktarım konusundaki işbirliğini güçlendirmek için ulusal idareler, piyasa gözetim otoriteleri, engelli sivil toplum kuruluşları, erişilebilirlik uzmanları ve sektör temsilcilerinden oluşan bir uzman grubu kurdu. Bu, yasanın kağıt üzerinde kalan bir taahhüt değil, aktif olarak takip edilen bir süreç olduğu anlamına geliyor.

Bir Türkiye merkezli geliştirici veya ajans için bu yasanın neden önemli olduğunu netleştirmekte fayda var: uygulamanı yalnızca Türkiye'de değil, App Store veya Play Store üzerinden AB ülkelerindeki kullanıcılara da sunuyorsan ve uygulaman bankacılık, e-ticaret, e-kitap gibi kapsam içi bir hizmet sağlıyorsa, EAA'nın seni ilgilendirip ilgilendirmediğini erken aşamada bir hukuk danışmanına sormak, sonradan ürünü baştan tasarlamaktan daha ucuza gelebiliyor.

Kapsam Dışı Kalabilen Uygulamalar

Her mobil uygulama bu yükümlülüğün altında değil. Direktifin 4(5). maddesi, 3(23). maddede tanımlanan mikro işletmeleri (10 kişiden az çalışanı olan ve yıllık cirosu veya bilançosu 2 milyon Euro'yu aşmayan işletmeleri) hizmet yükümlülüklerinden muaf tutuyor.

Bu istisnayı okurken dikkat etmen gereken nokta şu: muafiyet işletmenin büyüklüğüyle ilgili, uygulamanın türüyle değil. Yani küçük bir ekip tarafından geliştirilen ama büyük bir şirkete ait beyaz-etiket bir bankacılık uygulaması bu istisnadan yararlanamaz — asıl belirleyici, hizmeti sunan işletmenin çalışan sayısı ve cirosudur. Ayrıca istisna yalnızca "hizmet" sağlayan mikro işletmeler için geçerli; "ürün" üreten tarafta farklı kurallar işleyebilir. Kendi durumunun hangi kategoriye girdiğinden emin değilsen, bu değerlendirmeyi bir hukuk danışmanıyla netleştirmen en güvenli yol.

Teknik Karşılıklar: WCAG Kriterlerinin Mobildeki Hâli

EAA'nın hedeflediği erişilebilirlik seviyesi, dünya çapında en yaygın kabul gören ölçüt olan WCAG (Web Content Accessibility Guidelines) ile aynı dili konuşuyor: World Wide Web Consortium'un (W3C) kendi ifadesiyle "Seviye AA, Seviye A ve AA gereksinimlerinin tamamını kapsar." Birçok kuruluş Seviye AA'yı hedefliyor. Mobil dünyada bu, tek bir CSS kuralı veya HTML özniteliği değil; ekran okuyucu desteği, dokunma hedefi büyüklüğü, kontrast oranı ve odak sırası gibi platforma özgü karşılıklarla hayata geçiyor.

Burada iki büyük mobil platformun (iOS ve Android) kendi erişilebilirlik API'leri var ve her ikisi de WCAG'ın ardındaki aynı ilkeleri (algılanabilirlik, kullanılabilirlik, anlaşılabilirlik, sağlamlık) kendi bileşen modeline uyarlıyor. WCAG kriterlerinin kendisine daha geniş bir çerçeveden bakmak istersen Mobil Erişilebilirlik: WCAG Rehberi yazısına göz atabilirsin. Bir sonraki iki bölümde bu karşılıkları platform bazında görebilirsin.

iOS Tarafı: Erişilebilirlik Yaklaşımı

Apple'ın erişilebilirlik ekosistemi VoiceOver (ekran okuyucu), Dynamic Type (kullanıcının sistem genelinde ayarladığı yazı boyutuna uyum) ve kontrast/dokunma hedefi gibi görsel gereksinimler etrafında kuruluyor — bunlar Apple'ın kamuya açık, uzun süredir belgelediği ve iOS geliştirici ekosisteminde standart kabul edilen kavramlar. VoiceOver etiketleme ve Dynamic Type entegrasyonunun kod düzeyindeki ayrıntısı için sitedeki iOS Accessibility: VoiceOver'dan Dynamic Type'a Tam Rehber yazısına bak — orada VoiceOver etiketleme, Dynamic Type entegrasyonu ve kontrast/dokunma hedefi konuları uçtan uca, kod örnekleriyle işleniyor.

Uyum çalışmasında pratik olarak dikkat etmen gereken üç davranış kalıbı şu: her interaktif bileşenin VoiceOver ile anlamlı bir şekilde okunabilir olması, kullanıcı sistem yazı boyutunu büyüttüğünde arayüzün kırılmadan büyümesi ve görsel öğelerin (özellikle buton/ikon) yeterli kontrast ve dokunma alanıyla tasarlanması. Bu üç alanı denetlerken Apple'ın güncel geliştirici dokümantasyonuna bakmakta fayda var; spesifik eşik değerleri veya API isimleri için birincil referans her zaman Apple'ın kendi dokümantasyonu olmalı.

1// Temel VoiceOver etiketleme deseni — SwiftUI
2// Görsel bir simge butonuna anlamlı bir erişilebilirlik etiketi ekler.
3Button(action: addToCart) {
4    Image(systemName: "cart.badge.plus")
5}
6.accessibilityLabel("Sepete ekle")
7.accessibilityHint("Ürünü sepetine ekler")

iOS tarafında ben genelde şu hata kalıbıyla karşılaşıyorum: görsel bir ikonu tek başına bırakıp hiçbir erişilebilirlik etiketi eklememek — bu durumda VoiceOver kullanıcısı elemanın ne işe yaradığını anlayamıyor. Bir başka sık karşılaştığım hata, etiketi doğru ekleyip Dynamic Type'ı test etmemek: kullanıcı yazı boyutunu sistem ayarlarından büyüttüğünde metin kesiliyor veya buton dokunma alanının dışına taşıyor. Bu iki kalıbı yakalamanın en pratik yolu, geliştirme sürecinde en az bir kez cihazın erişilebilirlik ayarlarından en büyük yazı boyutunu seçip uygulamanın kritik ekranlarını bu ayarla gezmek — bu basit adım, görsel kırılmaları kod incelemesinden çok daha hızlı ortaya çıkarabiliyor.

Android Tarafı: TalkBack ve Teknik Karşılıklar

Android tarafında Google'ın resmi geliştirici dokümantasyonu, her UI elemanının amacını anlatan bir açıklama içermesi gerektiğini söylüyor: "Uygulamandaki her UI elemanı için, elemanın amacını anlatan bir açıklama ekle. Çoğu durumda bu açıklamayı contentDescription özniteliğine yazarsın." Bu açıklamalar görsel detayı değil, etkileşimin amacını ve sonucunu anlatmalı — yani bir gönder butonu için "Gönder" yeterli, "Gönder butonu" gereksiz bir tekrar (Android dokümantasyonunun kendi örneği tam olarak bu: "Submit", "Submit button" değil).

Dokunma hedefleri için Android'in kendi önerisi net: her etkileşimli UI elemanının odaklanabilir alanı, yani dokunma hedefi boyutu, en az 48dp x 48dp olmalı — "daha büyüğü daha da iyi" deniyor. Jetpack Compose kullanıyorsan Text bileşenleri için ayrıca contentDescription vermene gerek yok; TalkBack gibi erişilebilirlik servisleri metni otomatik olarak okuyor. Salt dekoratif bir öğe başka bir bileşenin parçasıysa (ör. bir Icon), contentDescription olarak null geçerek gereksiz etiketlemeyi önlemen öneriliyor.

Bir UI elemanının türünü (buton, switch, vb.) ekran okuyucuya bildirmek için Role semantics özelliğini (Role.Button, Role.Switch gibi) kullanman, TalkBack'in elemanı doğru anons etmesini sağlıyor.

Bu kuralların pratikte ihlal edildiğini en sık gördüğüm yer, kod tabanına sonradan eklenen küçük UI parçaları oluyor: bir tasarım güncellemesiyle eklenen yeni bir ikon butonu, bir A/B test varyantıyla gelen geçici bir banner ya da üçüncü parti bir SDK'nın kendi arayüz bileşeni. Bunların hiçbiri ilk yazıldığında "erişilebilirlik" başlığı altında düşünülmediği için contentDescription veya Role semantics genellikle atlanıyor. Bu yüzden erişilebilirlik denetimini yalnızca büyük sürüm çıkışlarında değil, her yeni interaktif bileşen eklendiğinde çalıştırman gerekiyor — bir sonraki bölümde bunu nasıl sürekli bir kapı hâline getirebileceğini görebilirsin.

1// Jetpack Compose — anlamlı contentDescription + Role semantics
2Icon(
3    imageVector = Icons.Filled.ShoppingCart,
4    contentDescription = "Sepete ekle", // "Sepete ekle butonu" değil
5    modifier = Modifier
6        .size(48.dp) // Android önerisi: minimum 48dp x 48dp'lik bir bileşen boyutu
7        .clickable(onClickLabel = "Sepete ekle", role = Role.Button) { addToCart() }
8)

Otomatik Denetim + Manuel Test Protokolü

Tek başına ne otomatik araçlar ne de manuel test yeterli — ikisini birlikte kurgulaman gerekiyor. Android tarafında Google'ın kendi önerisi şu: renk kontrastını online bir kontrast kontrolcüsü veya Accessibility Scanner uygulamasıyla denetle; kodunu ise contentDescription'ın beklendiği gibi iletildiğinden emin olmak için test et — Android Lint ve Compose testing araçları burada yaygın sorunları otomatik olarak yakalayabiliyor.

Pratikte üç katmanlı bir protokol işe yarıyor:

• Statik analiz: Android Lint / Compose testing (Android) — CI'da her PR'da otomatik çalıştır.
• Otomatik cihaz taraması: Accessibility Scanner (Android) ile gerçek ekranları tarayıp kontrast/etiket eksikliklerini listele.
• Manuel gezinti: VoiceOver/TalkBack açıkken uygulamanın kritik akışlarını (kayıt, ödeme, sepete ekleme) baştan sona, yalnızca ekran okuyucu ve klavye/switch kontrolüyle tamamla — otomatik araçların yakalayamadığı "mantıksal" sorunlar (yanlış okuma sırası, anlamsız etiket) burada çıkar.

Bu üç katmanı sırayla değil, birbirini tamamlayan bir döngü olarak düşün: statik analiz seni geliştirme anında uyarır, otomatik tarama sürüm öncesi son bir kontrol sağlar, manuel test ise ikisinin de göremediği kullanıcı deneyimi sorunlarını ortaya çıkarır. Sadece birini uygulayıp diğerlerini atlarsan, uyum dosyanda "test edildi" yazsa bile gerçek kullanıcı için bariyerler kalmaya devam eder.

1# Android — Lint denetimini CI kapısı olarak çalıştırmak için
2# Android Lint ve Compose testing, contentDescription eksikliği gibi
3# yaygın erişilebilirlik sorunlarını otomatik olarak yakalayabiliyor
4./gradlew lint

Uyum Dosyası ve Kanıt Saklama

EAA yükümlülüğü altındaysan, "erişilebilir hâle getirdik" demek yetmiyor — bunu kanıtlayabilmen gerekiyor. Komisyonun izleme modelinde ulusal piyasa gözetim otoriteleri devreye girebiliyor; bu yüzden denetim/test sonuçlarını, hangi sürümde hangi düzeltmenin yapıldığını ve kalan bilinen kısıtları içeren bir uyum dosyası tutmak, olası bir sorgulamada elini güçlendiriyor.

Pratikte bu dosyada şunlar bulunmalı:

• Test tarihi ve kapsamı: hangi ekranlar, hangi işletim sistemi sürümü, hangi ekran okuyucuyla test edildi.
• Bulgular ve düzeltme kayıtları: her bulgunun hangi sürümde kapatıldığı (commit/PR referansıyla).
• Otomatik tarama çıktıları: Accessibility Scanner, Lint gibi araçların ham raporları — sürüm etiketiyle arşivlenmiş.
• Bilinen kısıtlar ve yol haritası: henüz çözülmemiş sorunlar ve planlanan çözüm tarihi.

Bu dosyayı hazırlarken sık karşılaştığım bir hata, onu bir kerelik bir "teslim belgesi" gibi görmek — denetim bitince kapatıp bir daha açmamak. Oysa dosyanın asıl değeri, uygulaman her yeni sürüm çıkardıkça güncellenmesinde. Yeni bir ekran eklediğinde, mevcut bir akışı yeniden tasarladığında ya da üçüncü parti bir SDK entegre ettiğinde, bu dosyaya "bu sürümde şu test edildi, şu bulundu, şu düzeltildi" satırı eklemek, hem ekibinin erişilebilirliği unutmamasını sağlıyor hem de bir denetim talebi geldiğinde saatler süren geriye dönük araştırma yerine dakikalar içinde cevap verebilmeni sağlıyor. Küçük bir ekipsen, bu dosyayı ayrı bir araç yerine mevcut proje yönetim sisteminde (bir wiki sayfası, bir CHANGELOG bölümü) tutman yeterli — önemli olan format değil, sürekliliği.

SSS

Avrupa Erişilebilirlik Yasası mobil uygulamaları kapsıyor mu?

Evet. Avrupa Komisyonu'nun resmi kapsam listesinde akıllı telefonlar ayrı bir kalem olarak yer alıyor ve bankacılık, e-ticaret, e-kitap gibi hizmetler açıkça sayılıyor; bu hizmetleri sunan mobil uygulamalar yasanın kapsamına giriyor.

Uygulama tarihi ne zaman?

Yasanın asıl uygulama (compliance) tarihi 28 Haziran 2025. Üye Devletler direktifi daha önce, Haziran 2022'ye kadar ulusal hukuka aktarmakla yükümlüydü; 28 Haziran 2025 ise şirketlerin yeni pazara sürdükleri ürün ve hizmetleri fiilen erişilebilir hâle getirmesi gereken tarih.

Uyum için teknik olarak ne yapmalıyım?

Platformuna göre değişir: Android'de her interaktif elemana anlamlı bir contentDescription, en az 48dp x 48dp dokunma hedefi ve Role semantics ekle; iOS'ta VoiceOver etiketleme ve Dynamic Type desteğini sitedeki VoiceOver rehberinden takip et. Her ikisinde de otomatik tarama (Lint, Accessibility Scanner) ile manuel ekran okuyucu testini birlikte yürüt ve sonuçları bir uyum dosyasında sakla.

Uygulamam küçük bir ekip tarafından geliştiriliyorsa muaf mıyım?

Muafiyet, uygulamayı geliştiren ekibin değil, hizmeti sunan işletmenin büyüklüğüyle ilgili. Direktifin 3(23). maddesindeki mikro işletme tanımına göre 10 kişiden az çalışanı ve 2 milyon Euro'yu aşmayan ciro/bilançosu varsa, 4(5). maddedeki hizmet muafiyetine girebilirsin; ama bu değerlendirmeyi kendi durumuna göre bir hukuk danışmanıyla teyit etmen en güvenli yol.

Sadece App Store/Play Store'da mı, yoksa web sürümünde de mi uyum gerekiyor?

EAA kapsamı platforma özel bir ayrım yapmıyor; hizmetin kendisi (bankacılık, e-ticaret, e-kitap vb.) kapsamdaysa, o hizmete erişilen her kanal (mobil uygulama, web) için erişilebilirlik beklentisi geçerli. Bu yazı mobil uygulama tarafına odaklanıyor; web tarafındaki teknik karşılıklar için WCAG'ın kendisine bakman gerekiyor.

Güncelleme (Eylül 2026)

Bu makale 16 Nisan 2025'te, yani EAA'nın 28 Haziran 2025 uygulama tarihinden önce yazıldı. Aradan geçen sürede yasa fiilen yürürlüğe girdi ve denetim/standart tarafında somut gelişmeler yaşandı:

• 28 Haziran 2025 — EAA fiilen uygulamaya girdi. Bankacılık, e-ticaret, ulaşım bilet/bilgi uygulamaları, e-kitap gibi hizmetler için erişilebilirlik artık isteğe bağlı değil, yasal bir zorunluluk; AccessibleEU'nun kendi ifadesiyle bu tarih "kapsayıcılık için yeni bir dönemin" başlangıcı olarak tanımlanıyor.
• 14 Ekim 2025 — 5. Avrupa Erişilebilirlik Zirvesi, gündeminde artık EAA'nın _denetimi/uygulanması_ başlığı yer aldı — yasa artık kağıt üzerinde değil, fiilî gözetim aşamasında.
• 4 Haziran 2026 tarihli AccessibleEU duyurusuna göre CEN/CENELEC/ETSI kamu alımı rehberi yenilendi (belge Şubat 2026'da yayımlandı). 2014 tarihli iki ayrı teknik rapor tek belgede (CEN-CLC-ETSI/TR 101551:2026) birleştirildi; EN 301 549'u temel referans olarak öne çıkarıyor.
• 7 Eylül 2026 — EN 301 549 standardı v4.1.1'e güncellendi, referans WCAG sürümü 2.1'den 2.2'ye geçti (6 yeni kriter eklendi). Önemli nüans: hukuken bağlayıcı sürüm hâlâ v3.2.1 (2021) — v4.1.1 ancak AB Resmî Gazetesi'nde atıfla anıldığında zorunlu hale gelecek, ama kuruluşların şimdiden WCAG 2.2'ye göre hazırlanması öneriliyor.
• 5 Ağustos 2026 — Avrupa Merkez Bankası, dijital euro uygulamasını EAA'nın üzerinde tasarlıyor. Tam klavye navigasyonu, ekran okuyucu uyumu, sade dil ve azaltılmış hareket gibi planlanan özellikler arasında yer alıyor; bu, büyük ölçekli bir AB mobil uygulamasının EAA'yı referans alarak baştan tasarlandığı somut bir örnek.
• 24 Eylül 2026 tarihli bir analiz, erişilebilirlik şikayetlerinin neden nadir kaldığını inceliyor: kullanıcılar bariyerle karşılaşınca resmi şikayet yerine hizmeti terk ediyor ya da rakibe geçiyor. Analizin kendi uyarısı önemli: "şikayet azlığı, hizmetin erişilebilir olduğunun kanıtı değil."

Bu gelişmelerin ortak mesajı şu: EAA artık bir "gelecek tarih" değil, aktif olarak izlenen ve standart tarafında güncellenmeye devam eden bir yükümlülük. Uyum dosyanı hazırlarken hâlâ bağlayıcı olan EN 301 549 v3.2.1 / WCAG 2.1 AA'yı temel al, ama WCAG 2.2'ye geçişi de yol haritana ekle.

Sonuç

Avrupa Erişilebilirlik Yasası, mobil uygulamanı Avrupa pazarında tutuyorsan artık teorik bir gelecek yükümlülüğü değil, 28 Haziran 2025'te fiilen işlemeye başlayacak bir uyum gereksinimi. Kapsamını netleştirmek (hizmetin türü + işletme büyüklüğü), Android ve iOS tarafında platforma özgü teknik karşılıkları uygulamak ve bunu otomatik+manuel test protokolüyle sürekli doğrulamak, bu sürecin üç ana ayağı.

Bu makale hukuki/uyum eksenine odaklandı; iOS tarafındaki VoiceOver ve Dynamic Type uygulamasının teknik detayları için iOS Accessibility: VoiceOver'dan Dynamic Type'a Tam Rehber yazısına bakabilirsin. Uyum çalışmasını ürün ekibine anlatırken kullanıcı davranışı verilerine de ihtiyacın olacak — bu noktada Mobil Retention Metrikleri: D1, D7 ve D30'u Doğru Okumak yazısı faydalı olacaktır. Uyum sürecinin pazarlama/ölçümleme tarafındaki etkilerini görmek istersen Mobil Attribution: MMP Seçimi ve SKAdNetwork Ölçümleme yazısına, uygulamandaki değişiklikleri A/B test disipliniyle yayınlamak istersen Mobil A/B Test Altyapısı: Kurulum, İstatistik ve Tuzaklar yazısına göz atabilirsin.

Kaynaklar

• European Accessibility Act — European Commission — Yasanın resmi kapsamı, amacı ve izleme mekanizması.
• Directive (EU) 2019/882 — EUR-Lex — Madde 2(4) kapsam istisnaları, Madde 3(23) mikro işletme tanımı, Madde 3(30) e-ticaret hizmeti tanımı, Madde 4(5) muafiyeti ve Madde 31 uygulama tarihinin resmi metni.
• WCAG 2 AA Conformance — W3C WAI — Seviye AA uygunluğunun tanımı.
• Make apps more accessible — Android Developers — contentDescription, dokunma hedefi boyutu, Role semantics ve test protokolü.
• New era for inclusion begins as EAA enters into force — AccessibleEU — 28 Haziran 2025 uygulama tarihinin fiilen başlaması.
• European accessibility standard EN 301 549 has been updated — AccessibleEU — EN 301 549 v4.1.1 ve WCAG 2.2 geçişi.
• Digital euro app to incorporate highest accessibility standards — AccessibleEU — ECB dijital euro uygulaması örneği.
• Make your app more accessible — Accessibility Scanner, Android Developers — Accessibility Scanner'ın kontrast, dokunma hedefi ve etiket eksikliğini taradığının resmi kaynağı.