Mobil Uygulama Erişilebilirliği: WCAG 2.2 ve Platform Araçları

Erişilebilirlik, mobil uygulamalarda çoğu zaman geliştirme bittikten sonra hatırlanır. Oysa sorunların büyük kısmı tasarım dosyasında başlar: küçük bir ikon butonu, yalnız sürükleyerek çalışan bir sıralama, sabit yükseklikli bir kart ya da etiketi olmayan bir simge. Bu yazı WCAG 2.2'nin mobil uygulamalara nasıl uygulandığını, tasarımda en sık karşılaşılan ölçütleri ve Apple ile Android'in erişilebilirlik araçlarının tasarıma etkisini anlatıyor.

WCAG 2.2 mobil uygulamalara nasıl uygulanır?

WCAG, adı web içerik erişilebilirliği yönergeleri olsa da mobil uygulamalar için de ortak dildir. W3C'nin "Guidance on Applying WCAG 2.2 to Mobile Applications" belgesi, rehberliği yerel mobil uygulamalar, mobil web uygulamaları ve web bileşenleri içeren hibrit uygulamalar için ele alıyor 1. Belge Mayıs 2025 tarihli bir W3C grup taslak notu ve kendini açıkça bağlayıcı olmayan, yol gösterici bir metin olarak tanımlıyor 1.

Belgenin mobil ekiplere en yararlı yanı, web için yazılmış ölçütlerin uygulama ekranındaki karşılığını açıklamasıdır. Örneğin:

• 1.3.4 Yönlendirme: İçerik, görüntüsünü ve kullanımını dikey ya da yatay gibi tek bir ekran yönüne kilitlememeli 1.
• 1.4.4 Metni yeniden boyutlandırma: Metin, içerik ve işlev kaybı olmadan yüzde 200'e kadar büyütülebilmeli. W3C, web dışı yazılımlarda platformun her metni yüzde 200'e ölçeklemeyebileceğini, bu durumda platform ayarlarının desteklediği ölçüde ölçeklemenin teşvik edildiğini belirtiyor 1.
• 1.4.10 Yeniden akış: Küçük ekranda içerik, bilgi ve işlev kaybı olmadan ve iki yönde kaydırma gerektirmeden sunulmalı 1.

Pratikte mobil uygulama ekipleri de web ekipleri gibi WCAG 2.2 AA düzeyini hedef alır. Genel web erişilebilirliği ve WCAG'in temelleri için websitemx'in WCAG rehberine bakabilirsiniz; bu yazı uygulamaya özgü kısma odaklanıyor.

Dokunma hedefi: 24 piksel, 44 punto ve 48 dp

WCAG 2.2 ile gelen 2.5.8 Hedef Boyutu (Asgari) ölçütü, AA düzeyinde işaretçi girişi hedeflerinin en az 24 x 24 CSS pikseli olmasını istiyor. Beş istisna tanınıyor: aralık (küçük hedeflerin çevresindeki 24 piksel çaplı daireler kesişmiyorsa), eşdeğer (aynı işlev ölçütü karşılayan başka bir kontrolle yapılabiliyorsa), satır içi (hedef bir cümle içindeyse), kullanıcı aracısı kontrolü ve zorunlu sunum 2. W3C, CSS kullanılmayan teknolojilerde CSS pikseli tanımının nasıl uygulanacağını ayrıca açıklıyor 1; uygulamalarda bu karşılaştırma genellikle iOS'ta punto, Android'de dp gibi cihazdan bağımsız birimlerle yapılır.

Platformların önerileri bu asgarinin üzerinde:

Apple'ın güncel yönergesindeki ayrım dikkat çekici: 44 x 44 pt artık "varsayılan" kontrol boyutu, 28 x 28 pt ise "asgari" boyut olarak veriliyor 4. Apple aralığın da boyut kadar önemli olduğunu vurguluyor; çerçeveli öğelerin çevresinde yaklaşık 12 punto, çerçevesiz öğelerin görünür kenarı çevresinde yaklaşık 24 punto boşluğun iyi çalıştığını söylüyor 4. Tasarımda pratik kural: platform varsayılanını hedefleyin, küçük ikonlarda görünen simgeyi küçük tutsanız bile dokunma alanını büyütün.

Sürüklemeye alternatif ve hareket

2.5.7 Sürükleme Hareketleri ölçütü (AA), sürüklemeyle çalışan her işlevin, sürükleme zorunlu değilse, tek bir işaretçiyle sürüklemeden de yapılabilmesini istiyor 3. Bu ölçüt, sürükleme hareketini yapmakta zorlanan ya da yardımcı teknoloji kullanan kişiler için önemlidir. W3C'nin verdiği örnekler doğrudan tasarım kararlarına dönüşür 3:

1. Kaydırıcı: Kullanıcı çubuğun herhangi bir yerine dokunarak değeri o noktaya taşıyabilmeli.
2. Sıralanabilir liste: Bir öğeye dokunduktan sonra yanında "yukarı taşı" ve "aşağı taşı" kontrolleri çıkmalı.
3. Harita: Sürükleyerek gezinmenin yanında yön butonları olmalı.
4. Görev panosu: Kartı başka sütuna sürüklemenin yanında, karta dokununca açılan bir "taşı" menüsü olmalı.

Mobil uygulamalarda sola kaydırarak silme gibi kaydırma hareketleri de aynı gözle değerlendirilmeli: aynı eylem bir menüden ya da detay ekranından da yapılabiliyor mu? Animasyon tarafında Apple, hızlı ve yanıp sönen animasyonların bazı kişilerde baş dönmesine yol açabileceğini, Hareketi Azalt ayarı açıkken otomatik ve tekrarlayan animasyonların azaltılmasını öneriyor 4.

Ekran okuyucular: VoiceOver ve TalkBack

Görme engelli kullanıcılar uygulamayı iOS'ta VoiceOver, Android'de TalkBack ile kullanır. Ekran okuyucunun doğru çalışması, büyük ölçüde tasarımda verilen kararlara bağlıdır.

Apple'ın VoiceOver yönergesi şu noktaları öne çıkarıyor 5:

• Tüm önemli arayüz öğelerine alternatif etiket verin. Sistem kontrollerinin genel etiketleri vardır, ama işlevi anlatan daha açıklayıcı etiketler gerekir; özel öğelerin etiketi mutlaka tanımlanmalıdır.
• Anlamlı görselleri açıklayın, süs görsellerini dışarıda bırakın. Bilgi taşımayan görselleri okutmak kullanıcının zamanını harcar.
• Başlık ve bölüm başlıklarını tanımlayın. Ekran okuyucu kullanıcısı ekrana geldiğinde ilk duyduğu şey başlıktır.
• İlişkili öğeleri gruplayın. Görsel ile altındaki açıklama gibi birlikte anlam taşıyan öğeler gruplanmazsa VoiceOver önce bütün görselleri, sonra bütün açıklamaları okuyabilir.
• Görünür içerik değiştiğinde bildirin. Beklenmedik bir düzen değişikliği, kullanıcının ekranın zihinsel haritasını bozar.

Android tarafında ilke aynıdır: her arayüz öğesi için amacını anlatan bir açıklama verilir; metin öğeleri ise TalkBack tarafından zaten okunduğu için ayrıca açıklama gerektirmez 6. Tasarım teslim dosyasında bu, ikon butonlarının yanında okunacak etiketin ("Sepete ekle", "Bildirimi kapat") ve okuma sırasının yazılı olması demektir. Etiket metni bir UX yazımı işidir; "buton" ya da "ikon" gibi sözcükler içermemeli, eylemi söylemelidir.

Büyük yazı ve kontrast

Az gören ya da metni rahat okumak isteyen kullanıcılar sistem yazı boyutunu büyütür. Uygulamanın bu ayara uyması, tasarımda kolayca atlanan bir kalemdir.

Apple, insanların metni en az yüzde 200 büyütebilmesini idealde hedeflemeyi öneriyor; bunun için özel bir arayüz ya da sistem genelindeki Dynamic Type ayarı kullanılabilir 4. Android 14 ile sistem yazı boyutu yüzde 200'e kadar büyütülebiliyor; büyük metnin aşırı büyümemesi için doğrusal olmayan bir ölçekleme eğrisi kullanılıyor 7. Android, metin boyutlarının ve satır yüksekliğinin sp biriminde tanımlanmasını, boşlukların ise sp ile tanımlanmamasını öneriyor; doğrusal olmayan ölçekleme yüzünden sp değerleri artık toplanabilir değil 7.

Tasarım dosyasında bunun anlamı şudur: her ekranın en az bir büyük yazı varyantı hazırlanmalı, sabit yükseklikli kartlar ve butonlar metinle birlikte uzayabilmeli, iki sütunlu düzenler gerekirse tek sütuna dönebilmelidir.

Kontrastta Android, WCAG ile aynı oranları öneriyor: 18sp'den küçük metinde ya da 14sp'den küçük kalın metinde en az 4,5:1, diğer metinlerde en az 3:1 6. Android ayrıca kontrastı kontrol etmek için Accessibility Scanner uygulamasını öneriyor 6.

Mağaza etiketi ve Avrupa Erişilebilirlik Yasası

Erişilebilirlik artık mağaza sayfasında da görünür. Apple, uygulamanın erişilebilirlik desteğinin App Store'da Accessibility Nutrition Labels ile bildirilebildiğini belirtiyor 4. Bu, tasarım ekibinin hangi özelliğin gerçekten desteklendiğini bilmesini ve bunu ürün ekibiyle birlikte doğrulamasını gerektirir.

Yasal tarafta, AB'deki tüketicilere sunulan e-ticaret ve bankacılık hizmetleri Avrupa Erişilebilirlik Yasası (Direktif (AB) 2019/882) kapsamındaki hizmetler arasında 8. Direktifin e-ticaret tanımı web sitelerinin yanında mobil cihaz tabanlı hizmetleri de anıyor; yani AB'ye satış yapan bir uygulama da değerlendirme dışında kalmıyor. Kapsam, istisnalar ve tarihler için Avrupa Erişilebilirlik Yasası yazısına bakabilirsiniz.

Erişilebilirliği tasarım sürecine yerleştirmek

Erişilebilirliği sonradan eklemek, baştan tasarlamaktan her zaman daha pahalıdır. Sürece yerleştirmenin pratik yolu şu sıralamadır:

1. Design system bileşenlerine dokunma alanı, kontrast, odak durumu ve büyük yazı davranışını baştan tanımlayın; böylece her ekran bu kuralları miras alır. Bu konuda design system nedir yazısı başlangıç noktasıdır.
2. Her ekran tasarımına ekran okuyucu etiketlerini ve okuma sırasını not olarak ekleyin.
3. Sürükleme ve kaydırma hareketleri için alternatifi aynı ekran tasarımında gösterin.
4. Teslimden önce en büyük yazı boyutu, koyu mod ve yüksek kontrast varyantlarını kontrol edin.
5. Yayın öncesinde VoiceOver ve TalkBack ile ana akışları baştan sona deneyin; mümkünse yardımcı teknoloji kullanan katılımcılarla kullanılabilirlik testi yapın.

Mevcut bir uygulamanın erişilebilirlik sorunlarını ekran ekran bulmak için UX denetimi iyi bir başlangıçtır; yeni bir uygulamada ise bu kuralları baştan mobil uygulama tasarımı sürecine dahil ediyoruz.