Mobil uygulama erişilebilirliği: zorunlu mu, nasıl yapılır?

Uygulama erişilebilirliği zorunlu mu?

Hukuki danışmanlık değildir.Bu bölüm, iki rehberimde resmi metinden yaptığım özetin kısa bir tekrarıdır. Kendi durumunuz için resmi metni okuyun ve bir hukukçuya danışın.

Kısa cevap: genelgenin saydığı kuruluşlardan biriyseniz, büyük olasılıkla evet. 2025/10 sayılı Cumhurbaşkanlığı Genelgesi ikisini baştan sona birlikte anıyor: "web siteleri ve mobil uygulamalar".

Ölçüt iki belge: Bakanlığın "Kontrol Listesi - A Seviyesi" ve WCAG 2.2. Liste, soruların her mobil uygulama ekranı için ayrı değerlendirilmesini istiyor. Kimlerin kapsamda olduğunu ve süreleri erişilebilirlik genelgesi rehberinde resmi metinden aktardım.

Logo tarafında mobil için bir ayrıntı var. Bakanlık Yönergesi, erişilebilir mobil uygulamaları her mobil işletim sistemi için ayrı anıyor. iOS ve Android'i iki ayrı ürün gibi planlayın; adımlar Erişilebilirlik Logosu rehberinde.

WCAG mobil uygulamaya nasıl uygulanır?

W3C mobil için ayrı bir kılavuz yazmıyor. WAI'nin mobil erişilebilirlik sayfasına göre WCAG, mobil cihazlarda kullanılan içeriği de kapsıyor. Aynı sayfa, WCAG 2.1 ve 2.2'ye mobil erişilebilirlikle ilgili yeni başarı kriterleri eklendiğini yazıyor.

Uygulamalar için yardımcı bir belge de var: WCAG2Mobile. 6 Mayıs 2025 tarihli bir taslak not; bağlayıcı değil, bilgi amaçlı. WCAG 2.2'nin A ve AA kriterlerini yerel, hibrit ve mobil web uygulamalarına uyguluyor.

Bence belgenin en işe yarayan kısmı şu: web'deki "sayfa", uygulamada tek bir ekrana karşılık geliyor. Bakanlığın listesi de her ekranı ayrı istiyor, mantık aynı. Belge kendi sınırını da yazıyor: tek başına yeterli değil.

WCAG 2.2, 12 Aralık 2024 tarihli W3C Tavsiyesi. Kriterlerin tamamını ve seviyeleri WCAG rehberinde anlattım. Bu sayfada mobilde en sık kırılan konulara bakıyorum.

Ekran okuyucu: VoiceOver ve TalkBack

iPhone'da ekran okuyucunun adı VoiceOver, Android'de TalkBack. Apple VoiceOver'ı jestlerle kullanılan ve ekrandakini sesle anlatan bir ekran okuyucu olarak tanımlıyor. TalkBack ise Android'in anlatımıyla içeriği görmeyen ya da az gören kişiler için sentezlenmiş sesle okuyor.

Apple'ın test rehberine göre VoiceOver açıkken sağa ya da sola kaydırmak bir sonraki ya da önceki öğeyi seçer. Kullanıcı her öğede öğenin adını, rolünü ve varsa durumunu duymalı. WCAG 2.2'deki 4.1.2 Ad, Rol, Değer kriteri (A düzeyi) adın ve rolün programla belirlenebilmesini istiyor.

Aşağıdaki ekranı iki halde deneyin. Önce etiketsiz halde baştan sona gezin, sonra etiketli hale geçip aynısını yapın.

Ekran okuyucu ve yazı boyutu

Fatura öde

Abone numarası Abone noÖrn. 1042 7781 Faturanızın sol üst köşesinde yazar.

248,60 TL öde

Bir fatura ödeme ekranının iki hali. Sonraki öğe düğmesiyle ekran okuyucu gibi gezin; okunan metin sarı kutuda görünür. Kaydırıcı yazıyı büyütür, kesik çizgili çerçeve yazısı kesilen öğeyi gösterir. Okunan sözcükler temsilidir; gerçek ekran okuyucunun söyledikleri sürüme ve dile göre değişir.

JavaScript kapalıysa aynı karşılaştırmayı şu tabloda okuyabilirsiniz.

Sıra	Etiketsiz ekranda okunan	Etiketli ekranda okunan
1	Düğme.	Geri, düğme.
2	248,60 TL öde, düğme.	Favorilere ekle, anahtar, kapalı.
3	ic_star_outline, düğme.	Fatura öde, başlık.
4	Fatura öde.	Abone numarası, metin alanı. Faturanızın sol üst köşesinde yazar.
5	Resim.	248,60 TL öde, düğme.
6	Metin alanı.	Okunacak öğe kalmadı. Süs görseli atlandı.

Etiket nasıl yazılır?

Apple'ın kuralı açık: önemli her arayüz öğesine bir alternatif etiket verin ve arayüz değiştikçe etiketi güncel tutun. Süs görsellerini ise VoiceOver'dan gizleyin.

Android tarafında etiket contentDescription ile verilir. Yazı içeren öğeler için gerekmez, çünkü TalkBack yazıyı kendisi okur. Demodaki Öde düğmesi etiketsiz halde de doğru okunuyor, nedeni bu.

Android'in iki pratik uyarısı var. Etikete rolü yazmayın: "Gönder düğmesi" değil, "Gönder". Listede her öğeye ayrı bir etiket verin; kullanıcı bir etiketi yeniden duyduğunda aynı öğeye döndüğünü anlar.

Dinamik yazı boyutu

Kullanıcılar telefonun yazı boyutunu ayarlardan büyütür. Apple bu sistem ayarına Dynamic Type diyor ve yazının ideal olarak en az yüzde 200 büyüyebilmesini öneriyor. WCAG 2.2'deki 1.4.4 kriteri de (AA düzeyi) yüzde 200'e kadar büyütmede içerik ya da işlev kaybı olmamasını istiyor.

Kayıp çoğu zaman kesilen yazı olarak görünür. W3C'nin F69 kodlu başarısızlık örneği bunu anlatıyor: büyütme metni ya da kontrolleri kesiyor, kırpıyor veya örtüyorsa kriter sağlanmaz.

Yukarıdaki demoda kaydırıcıyı %200'e çekin. Etiketsiz halde başlık, metin alanı ve Öde düğmesi sabit yükseklikte olduğu için yazı kesilir. Etiketli halde kutular yazıyla birlikte büyür.

Apple'ın test listesi de aynı şeyi soruyor: büyük erişilebilirlik boyutlarında yerleşim yeniden akmalı, yazı kesilmemeli, öğeler üst üste binmemeli.

Dokunma hedefi

Apple'ın tablosunda iOS için varsayılan kontrol boyutu 44 × 44 pt, en küçük boyut 28 × 28 pt. Android her etkileşimli öğe için en az 48 dp × 48 dp öneriyor ve "daha büyüğü daha iyi" diyor.

WCAG 2.2'nin 2.5.8 kriteri (AA düzeyi) daha düşük bir alt sınır koyuyor: 24 × 24 CSS piksel, birkaç istisnayla. Ben mobilde platformun kendi önerisini hedeflerim, WCAG'yi taban sayarım.

Boşluk da önemli. Apple, çerçeveli öğelerin çevresinde yaklaşık 12 pt, çerçevesizlerde yaklaşık 24 pt boşluğun iyi çalıştığını yazıyor. Ölçüleri ve parmak testini dokunma alanı kalıbında ayrıntılı anlattım.

Kontrast

WCAG 2.2'nin 1.4.3 kriteri (AA düzeyi) metinde en az 4,5:1 kontrast istiyor, büyük metin için daha düşük bir eşik koyuyor. Android aynı eşiği kendi birimiyle yazıyor: 18 sp'den küçük metinde ya da 14 sp'den küçük kalın metinde 4,5:1, diğer metinlerde 3:1.

Apple, Accessibility Inspector'ın WCAG AA değerlerini kullandığını yazıyor: 17 pt'ye kadar metinde 4,5:1, 18 pt metinde ve kalın metinde 3:1.

Apple iki şey daha istiyor. Karanlık mod varsa kontrastı iki modda da ölçün. Varsayılan renkler yetmiyorsa, Kontrastı Artır ayarı açıkken daha güçlü bir renk şeması sunun.

Renklerinizi kontrast hesaplayıcıda ölçebilirsiniz. Android, kontrastı Accessibility Scanner uygulamasıyla kontrol etmeyi de öneriyor.

Hareket azaltma

Ekrandaki hareket bazı kişilerde baş dönmesi ve bulantı yapar. W3C, iç kulak kaynaklı bu tepkilerin arasında baş ağrısını da sayıyor. Apple'a göre bu etkilere yatkın kişiler Hareketi Azalt ayarını açabiliyor.

Ayar açıkken uygulama, kendiliğinden başlayan ve tekrar eden animasyonları azaltmalı: yakınlaşma, ölçeklenme, ekranın kenarındaki hareket. Apple'ın önerileri de somut. Yaylı animasyonların zıplamasını azaltın, eksen boyunca kayan geçişlerin yerine yavaşça belirip kaybolan geçişler kullanın.

WCAG'de bunun karşılığı 2.3.3 kriteri; AAA düzeyinde olduğu için Bakanlığın A seviyesindeki kontrol listesinin dışında kalıyor. Ben yine de bu ayara uyulmasını isterim, çünkü çoğu projede küçük bir iş. Bu sitede de animasyonlar bu ayar açıkken duruyor.

Jestlere alternatif

Kaydırarak silmek ya da iki parmakla yakınlaştırmak hızlıdır, ama her kullanıcı bu jestleri yapamaz. WCAG 2.2'nin 2.5.1 kriteri (A düzeyi) şunu istiyor: çok parmaklı ya da iz süren bir jestle yapılan iş, tek parmakla ve iz sürmeden de yapılabilmeli. Jest zorunluysa istisna var, sürükleme ise 2.5.7 kriterinde ele alınıyor.

W3C'nin örneği bir harita: iki parmakla yakınlaştırmanın yanında artı ve eksi düğmeleri. Apple da aynı şeyi söylüyor: bir görünümü kaydırarak kapatıyorsanız, dokunulabilecek bir düğme de koyun.

Ekran okuyucu açıkken kaydırma jesti öğeler arasında gezmeye yarar, bu yüzden kaydırarak yapılan işin başka bir yolu olmalı. Android bunun için kaydırma ve sürükleme gibi işlere özel erişilebilirlik eylemleri (customActions) öneriyor. Belgedeki örnekte bir makale kaydırılarak listeden kaldırılıyor; aynı iş eylemler menüsünde "listeden kaldır" olarak da sunuluyor.

Odak sırası

Ekran okuyucu öğeleri bir sırayla okur. Apple'a göre bu sıra, o dildeki okuma sırasıdır; İngilizcede yukarıdan aşağı, soldan sağa. Android'in Compose belgesi de varsayılanı soldan sağa, sonra yukarıdan aşağı diye anlatıyor.

Sorun, görsel düzen bu sırayla örtüşmediğinde çıkar. Android'in örneğinde iki sütunlu bir düzen satır satır okunuyor ve cümleler birbirine karışıyor. Çözüm, ilgili öğeleri isTraversalGroup ile gruplamak, gerekirse traversalIndex ile sıralamak.

WCAG 2.2'nin 2.4.3 kriteri (A düzeyi) bunu istiyor: odak, anlamı ve kullanımı koruyan bir sırayla ilerlemeli. Demodaki etiketsiz ekranda Öde düğmesinin ikinci okunması bu kuralı bozuyor.

Form etiketleri

WCAG 2.2'nin 3.3.2 kriteri (A düzeyi) kısa: kullanıcıdan bilgi isteniyorsa etiket ya da yönerge olmalı. Mobilde en sık gördüğüm kısayol, etiketi kaldırıp yalnızca alanın içindeki silik ipucunu bırakmak.

Android de ikisini ayırıyor. İpucu metni geçerli bir girişe örnek verir; etiket ise alana ne yazılacağını anlatır. Demodaki etiketli alanda ikisi birlikte duruyor: "Abone numarası" etiketi ve "Örn. 1042 7781" ipucu.

Etiketin yanında doğru klavye ve anlaşılır hata mesajı da gerekir. Bunları mobil form klavyesi ve hata mesajları kalıplarında ayrı ayrı anlattım.

Başlıklar, gruplar ve ekran yönü

Ekran okuyucu kullanıcısı her öğeyi tek tek dinlemez. Apple'ın VoiceOver rotoru, kişinin bir belgede ya da web sayfasında başlıklar ve bağlantılar arasında atlamasını sağlıyor. Atlamanın çalışması için başlığın kodda başlık olarak işaretlenmesi gerekir.

Android'de bu iş Compose'daki heading() özelliğiyle yapılıyor. Belge, kullanıcıların paragraflar yerine başlıklar arasında gezmeyi seçebildiğini yazıyor. Demodaki etiketli ekranda "Fatura öde, başlık" diye okunan satır bunun örneği.

Gruplama da okuma süresini kısaltır. Android, bir şarkının ayrıntıları gibi birbirine ait öğelerin mergeDescendants ile tek seferde okunmasını öneriyor. Bu durumda yalnızca kapsayıcı öğe etkileşimli olmalı, içindekiler değil.

Rengi tek ipucu olarak kullanmayın. Android'in örneğinde yalnızca yeşil ve kırmızıyla ayrılan iki düğme, yazı ve simge eklenince renk görme sorunu olan kullanıcılar için de anlaşılır oluyor.

Ekran yönü için WCAG 2.2'nin 1.3.4 kriteri (AA düzeyi) var: yön gerçekten zorunlu değilse içerik dikey ya da yatay tek bir yöne kilitlenmemeli. W3C'nin verdiği örnek: bazı kullanıcıların cihazı, elektrikli tekerlekli sandalyenin koluna sabit bir yönde takılı. Bu kişi telefonu çeviremez, uygulamanın o yönde çalışması gerekir.

Nasıl test edilir?

Apple'ın test rehberi işe ana görevleri listeleyerek başlamayı öneriyor. Önce her ekranda yapılabilecek ana işleri yazın, örneğin giriş yapmak ya da fatura ödemek. Sonra bu işleri her ayar ve yardımcı teknolojiyle tek tek deneyin.

1. Gerçek cihaz kullanın. Apple, VoiceOver'ın Simülatör'de çalışmadığını yazıyor. Uygulamayı telefona kurun.
2. Ekran perdesini açın. VoiceOver açıkken üç parmakla üç kez dokunmak ekranı karartır. Böylece yalnızca sese güvenen birinin deneyimini yaşarsınız.
3. Yazıyı en büyüğe alın. Ayarlardaki büyük erişilebilirlik boyutlarını açın ve her ana görevi yeniden yapın. Kesilen yazı ve üst üste binen öğe arayın.
4. Hareketi Azalt ve Kontrastı Artır ayarlarını açın. Uygulamanın bu ayarlara gerçekten tepki verip vermediğine bakın.
5. Android'de TalkBack ile aynısını yapın. Kontrastı Accessibility Scanner uygulamasıyla da kontrol edin.

Apple'ın listesindeki ölçüt basit: kullanıcı uygulamadaki her işi yalnızca VoiceOver ile bitirebilmeli. Web tarafındaki yöntemi erişilebilirlik denetimi rehberinde adım adım yazdım.

Apple ayrıca App Store ürün sayfasına Erişilebilirlik Besin Etiketleri eklemeye izin veriyor. Uygulamanın her platformda hangi özellikleri desteklediğini orada belirtirsiniz, bu yüzden beyandan önce test edin.

Benim notum

Mobil audit'lerde en sık gördüğüm hata etiketsiz simge düğmeleri. Geri oku, kalp, üç nokta menüsü, filtre simgesi. Tasarım dosyasında hepsi anlaşılır görünür ama ekran okuyucu "düğme" deyip geçer.

İkincisi sabit yükseklikli kutular. Tasarım %100 yazı boyutunda onaylanır, kimse %200'e bakmaz. Ben her ekranı en az iki boyutta kontrol ederim ve kesilen yazıyı hata olarak yazarım.

Düzeltmeyi tek tek ekranlarda değil, bileşende yapın. Bir düğme bileşeni etiket isterse onu kullanan her ekran düzelir. Bu işin en ucuz yeri tasarım sistemi.

Uygulamanızı bu gözle kontrol ettirmek isterseniz UX Audit WCAG 2.2'nin temel kontrollerini de içerir. Genelgeye uyum belgesi değildir ama nereden başlayacağınızı gösterir.