Mobil Uygulama Erişilebilirliği: iOS ve Android için WCAG 2.2 Gereksinimleri

Engelli yetişkinlerin %72’sinden fazlası bir akıllı telefona sahip ve bir ankete göre ekran okuyucu kullanıcılarının yaklaşık %86’sı ağırlıklı olarak mobil cihaza güveniyor — bu oran masaüstü veya dizüstü bilgisayar kullanıcılarından daha yüksek. Yine de web sitelerini düzenli olarak denetleyen aynı kuruluşların, tek bir erişilebilirlik kriterine göre bile test edilmemiş mobil uygulamaları sıklıkla bulunuyor. Bu boşluk hızla kapanıyor; bunun itici gücü değişen mevzuat, artan dava sayıları ve — en önemlisi — W3C’nin WCAG 2.2’yi yerel iOS ve Android uygulamalarına açıkça eşleyen kendi rehberliği.

WCAG 2.2 Neden Mobil Uygulamanız İçin Geçerli

WCAG’nin yalnızca web’e özgü bir standart olduğu yönünde ısrarlı bir mit var. Bu doğru değil. W3C’nin mobil erişilebilirlik için ayrı yönergeleri yok — bunun yerine mobil erişilebilirlik mevcut WCAG çerçevesi içinde ele alınıyor ve W3C’nin Mobile Accessibility Task Force’u (MATF), her A ve AA seviye başarı kriterini yerel mobil uygulamalara, mobil web uygulamalarına ve hibrit uygulamalara eşleyen Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile) adlı özel bir rehber hazırladı.

Pratik sonuç oldukça önemli. Bir WCAG başarı kriterinde “web sayfası” ifadesini okuduğunuzda, WCAG2Mobile belgesi bu dili “ekran” veya “görünüm” ile değiştiriyor. Bir kriter “kullanıcı aracısından” bahsettiğinde, bu mobil işletim sistemi anlamına geliyor. Dört POUR ilkesi — Algılanabilir (Perceivable), İşletilebilir (Operable), Anlaşılabilir (Understandable), Sağlam (Robust) — iOS’ta bir SwiftUI görünümüyle veya Android’de bir Jetpack Compose yerleşimiyle kullanıcının etkileşimini doğrudan karşılıyor.

Hukuki açıdan baskı artık teorik değil. ADA’nın II. Başlığı kapsamında, Nisan 2024’te yayımlanan güncel DOJ düzenlemeleri, eyalet ve yerel yönetimlerin mobil uygulamalarını WCAG 2.1 AA düzeyinde erişilebilir hale getirmesini açıkça zorunlu kılıyor. Medicare veya Medicaid kabul eden sağlık kuruluşları, Mayıs 2024’te kesinleşen HHS kuralları kapsamında benzer gerekliliklerle karşı karşıya. Özel sektörde mobil uygulama davaları hâlâ web sitesi davalarından daha az olsa da, en az bir yüksek hacimli davacı, ADA kapsamında eşit erişim eksikliği nedeniyle özellikle mobil uygulamaları hedef aldı ve II. Başlık uyum takvimleri 2026’da devreye girdikçe bu eğilimin hızlanması bekleniyor.

28 Haziran 2025’te yürürlüğe giren ve varsayılan teknik standardı olarak EN 301 549’a dayanan Avrupa Erişilebilirlik Yasası (EAA), AB pazarlarında sunulan veya satılan mobil uygulamalar da dahil olmak üzere dijital ürün ve hizmetler için WCAG 2.2’ye uygunluğu zorunlu kılıyor. Küresel bir kullanıcı tabanına sahip herhangi bir kuruluş için mobilde WCAG 2.2 bir gelecek hedefi değil — mevcut bir yükümlülük.

Mobil İçin En Çok Önem Taşıyan WCAG 2.2 Değişiklikleri

Ekim 2023’te W3C Tavsiyesi olarak yayımlanan WCAG 2.2, dokuz yeni başarı kriteri ekliyor ve artık geçersiz olan 4.1.1 Parsing’i kaldırıyor. Tamamen geriye dönük uyumlu: 2.2’ye uyum, 2.1 ve 2.0’a da uyumu ima ediyor. Yeni kriterlerin birkaçı, mobil etkileşim kalıpları açıkça göz önünde bulundurularak yazıldı ve klavye kullanımı etrafında çerçevelenenler bile iOS ve Android’deki yardımcı teknolojilerde doğrudan karşılık buluyor.

Buradaki kökeni anlamaya değer. 2018 sonrasında Mobile Accessibility Task Force, mobil hususların hem WCAG 2.1’i hem de 2.2’yi şekillendirmesini sağladı. 1.3.4 Orientation (AA), 1.4.10 Reflow (AA), 2.5.1 Pointer Gestures (A), 2.5.4 Motion Actuation (A) ve yeni 2.5.7 Dragging Movements (AA), 2.5.8 Target Size Minimum (AA) ve 3.3.7 Redundant Entry (A) gibi kriterlerin tümü, akıllı telefonlar ve tabletlerde engelli kullanıcılarla yapılan gerçek dünya testleriyle belirlenen belirli mobil kullanılabilirlik kalıplarını yansıtıyor.

WCAG 2.2’de tanıtılan dokuz yeni başarı kriteri, gerçek kullanıcıların karşılaştığı belirli engelleri hedefliyor: hafıza sorunu yaşayan herkesi cezalandıran oturum açma akışları, hassas dokunuşlar için sabit eller gerektiren arayüzler, her ekranın farklı yerlerine gömülmüş yardım özellikleri ve yapışkan gezinme çubuklarının arkasında kaybolan odak göstergeleri. Her kriter somut bir boşluğu kapatıyor — ve neredeyse hepsinin doğrudan mobil uygulama karşılığı var.

Yeni WCAG 2.2 Kriterleri ve iOS ile Android’e Uygulanmaları

2.5.8 Target Size Minimum (Seviye AA)

Bu, mobil ekipler için muhtemelen en etkili yeni kriter. Etkileşimli hedeflerin — düğmeler, bağlantılar, form alanları, onay kutuları, anahtarlar — en az 24 × 24 CSS piksel boyutunda olmasını veya hedefin kendisi daha küçükse bitişik hedefler arasında 24 piksel boşluk bulunmasını gerektiriyor. Gerekçe basit: el titremesi, Parkinson hastalığı veya sınırlı becerisi olan kullanıcılar için 16 piksellik bir simge düğmeye güvenilir şekilde dokunmak gerçekten imkansız ve engeli olmayan kullanıcılar bile küçük hedeflerde anlamlı derecede daha fazla hata yapıyor.

Yerel mobil geliştirme için WCAG 2.2’nin 24 × 24 minimumu aslında bir taban, tavan değil. Apple’ın Human Interface Guidelines dokümanı iOS ve iPadOS’te minimum dokunma hedefi olarak 44 × 44 point öneriyor. Google’ın Material Design rehberi Android’de 48 × 48 yoğunluktan bağımsız piksel (dp) öneriyor. Uygulamanız Apple’ın veya Google’ın platform rehberliğini karşılıyorsa, zaten WCAG 2.2 minimumunu aşıyorsunuz — ancak birçok uygulama bunu yapmıyor. Modal sayfalardaki o küçücük kapatma düğmeleri, ayarlar ekranlarındaki incecik onay kutuları ve 20 × 20 dp ölçülerindeki yalnızca simge içeren araç çubuğu eylemleri, bir denetimde ortaya çıkarılmayı bekleyen uyum hataları.

Pratik bir not: WCAG’nin gerekliliği etkileşimli tıklanabilir alan ile ilgilidir, simgenin görsel boyutuyla değil. Her bir kenarında 14 point dolgu bulunan 16 point’lik bir simge, 44 × 44 point’lik etkin bir dokunma hedefi sunar. Bu, geliştiricilerin öğeleri görsel olarak büyütmeden kriteri karşılayabileceği anlamına gelir — ancak bunu sistemin otomatik olarak yapacağına güvenmek yerine bu dolguyu bilinçli olarak ayarlamaları gerekir.

2.5.7 Dragging Movements (Seviye AA)

Bu kriter, sürükleme hareketiyle uygulanan herhangi bir işlevselliğin — kaydırıcılar, sürükle-bırak sıralama, yenilemek için çekme, karusel sürükleme — sürükleme gerektirmeyen tek işaretçi eylemiyle de gerçekleştirilebilir olmasını gerektirir. iOS ve Android’de platformun kendi yardımcı teknolojileri belirli hareketleri farklı şekilde ele alır, ancak uygulamanın kendisi, uyguladığı her özel sürükleme davranışı için sürükleme dışı alternatifler sunmalıdır.

Pratikte bu, sürükleyerek yeniden sıralanan bir listenin “yukarı/aşağı” adım düğmesi gibi bir alternatif sunması gerektiği anlamına gelir. Yalnızca sürükleme hareketine yanıt veren özel bir aralık kaydırıcısı, belirli noktalara dokunmalara da yanıt vermeli veya artış/azalış düğmeleri sağlamalıdır. Kriter, temel işletim sistemi veya yardımcı teknoloji alternatifi otomatik olarak sağlıyorsa geçerli değildir, ancak geliştiriciler bunun her zaman onlar adına ele alınacağını varsaymak yerine bunu açıkça test etmelidir.

2.4.11 Focus Not Obscured — Minimum (Seviye AA) ve 2.4.12 (Geliştirilmiş, Seviye AAA)

Bu kriterler, hem web hem de yerel mobil uygulamalarda son derece yaygın olan bir kalıbı ele alır: odaklanmış öğenin yapışkan bir arayüz tarafından kısmen veya tamamen gizlenmesi — kalıcı bir alt gezinme çubuğu, kayan bir eylem düğmesi, kaydırma alanıyla çakışan üst araç çubuğu gibi. Minimum kriter (Seviye AA), bir bileşen odak aldığında en azından bir kısmının görünür kalmasını gerektirir. Geliştirilmiş sürüm (Seviye AAA) ise odaklanmış bileşenin tamamının görünür olmasını şart koşar.

Yerel mobilde “klavye odağı”, Switch Control veya Switch Access, Full Keyboard Access (iOS 15+) ve Voice Control/Access tarafından kullanılan odak halkasını da kapsayacak şekilde geniş yorumlanır. Odaklanmış öğenin bir Switch Control taraması sırasında alt gezinme çubuğunun altına kaydığı bir uygulama, fiziksel bir klavye olmasa bile bu kriteri karşılamaz. Uygulama arayüzü, geliştirici tarafından oluşturulan katmanlar, yapışkan çubuklar veya geçici yüzeylerle odaklanmış kontrolleri gizlemekten kaçınmalıdır.

2.4.13 Focus Appearance (Seviye AA)

Bu kriter, odak göstergesinin görsel özellikleri için minimum gereklilikler belirler: bileşenin çevresi × 2 CSS pikseline eşdeğer minimum bir alana ve bitişik renklere karşı en az 3:1 kontrast oranına sahip olmalıdır. Yerel mobil platformlarda VoiceOver ve TalkBack için odak halkası işletim sistemi tarafından kontrol edilir ve geliştiriciler bunun görünümünü değiştiremez — bu da geliştiricilere bu özel kriter için genellikle bir istisna tanındığı anlamına gelir. Ancak uygulama stilinin, örneğin odaklanmış kontrollerin üzerine yarı saydam bir katman yerleştirerek odak görünürlüğünü aktif olarak azaltmaması gerekir.

3.3.8 Accessible Authentication — Minimum (Seviye A)

Bu kriter, bilişsel erişilebilirlik için büyük bir adımı temsil eder. Kimlik doğrulama süreçlerinin yalnızca bilişsel bir işlev testine dayanmamasını gerektirir — yani uygulama, kullanıcıya bir parolayı ezberlemesini, bir bulmacayı çözmesini veya bir CAPTCHA’yı kopyalamasını zorunlu kılmamalıdır — aksi halde erişilebilir bir alternatif sunmalıdır. iOS’ta bu, kullanıcıların kimlik bilgilerini ezberlemeden kimlik doğrulaması yapmasına olanak tanımak için Apple’ın Keychain’ini ve Sign in with Apple’ı desteklemek anlamına gelir. Android’de bu, Google’ın Autofill çerçevesini, biyometrik kimlik doğrulamayı desteklemek ve üçüncü taraf parola yöneticilerinin kullanımını engellememek anlamına gelir.

Daha somut olarak: Uygulamanız parola alanlarında yapıştırma işlemlerini engelliyorsa, muhtemelen 3.3.8 ile uyumlu değildir. İki faktörlü kimlik doğrulama akışınız, kullanıcıya bir bildirime gelen OTP kodunu kopyala-yapıştır mekanizması sunmadan manuel olarak yazmasını gerektiriyorsa, gereksiz bir bilişsel yük getirir. Android’in Messages uygulaması, tam da bu nedenle OTP bildirimlerinde “kodu kopyala” düğmesi sunuyor — platform davranışını kriterin amacıyla hizalıyor.

Temel içgörü: Biyometrik kimlik doğrulamayı (Face ID, Touch ID, Android Biometric API) desteklemek yalnızca bir UX iyileştirmesi değil — parolaları güvenilir şekilde hatırlayamayan bilişsel engelli kullanıcılar için WCAG 2.2 uyum mekanizmasıdır.

3.3.7 Redundant Entry (Seviye A)

Uygulamanızdaki çok ekranlı bir akış — ödeme, kullanıcı kaydı, sağlık kabul formu — kullanıcının aynı bilgiyi birden fazla kez girmesini istiyorsa, daha önce girilen değeri otomatik olarak doldurmalı veya önceki girdiden seçme imkanı sunmalısınız. Bu kriter, yerel mobil uygulamalara doğrudan uygulanabilir. Klasik hata, daha sonra “fatura adresi” isteyen ancak “teslimat adresiyle aynı” seçeneği sunmayan bir teslimat adresi formudur; bu, motor bozukluğu veya bilişsel engeli olan kullanıcıları aynı metni defalarca yeniden yazmaya zorlar.

3.2.6 Consistent Help (Seviye A)

Uygulamanız bir yardım mekanizması sunuyorsa — destek sohbet düğmesi, yardım simgesi, “bize ulaşın” bağlantısı — bu mekanizma uygulamadaki tüm ekranlarda tutarlı bir konumda görünmelidir. Bilişsel engelli kullanıcılar, gezinme ve destek mekanizmalarının öngörülebilir konumuna güvenir. Yardım düğmesini bazı ekranlarda üst kısma, bazılarında sekme çubuğuna yerleştirmek veya belirli akışlarda ayarlar menüsünün içine gömmek bu kriteri ihlal eder.

Mobil İçin Hâlâ Kritik Olan WCAG 2.1 Kriterleri

Yeni WCAG 2.2 kriterleri en çok ilgiyi çekiyor, ancak özellikle mobil düşünülerek tanıtılan birkaç WCAG 2.1 gerekliliği yerel uygulamalarda hâlâ rutin olarak ihlal ediliyor ve uyum yöneticileri denetimler sırasında bunları gözden kaçırmamalı.

1.3.4 Orientation (AA), içeriğin işlevi için zorunlu olmadıkça bir uygulamanın dikey veya yatay yönlendirmeye kilitlenmesini yasaklar. Birçok uygulama, kullanıcı kaydı akışları veya uygulama içi video oynatıcılar sırasında gerekçe olmaksızın dikeye kilitlenir. Bu, cihazları tekerlekli sandalyeye monte edilmiş ve döndürülemeyen kullanıcıları orantısız şekilde etkiler. 1.4.10 Reflow (AA), içerik 320 CSS piksel genişliğinde (400% yakınlaştırmaya eşdeğer) görüntülendiğinde yatay kaydırma olmadan sunulabilmesini gerektirir; bu, mobil terimlerle, düzeni bozmadan veya içeriği kesmeden Dynamic Type ve sistem metin boyutu ölçeklendirmesini desteklemek anlamına gelir.

2.5.1 Pointer Gestures (A), çok noktalı veya yol tabanlı hareketler — yakınlaştırmak için sıkıştırma, iki parmakla kaydırma — kullanan herhangi bir işlevselliğin tek işaretçi alternatifi olmasını gerektirir. 2.5.4 Motion Actuation (A), cihazı sallayarak veya eğerek tetiklenen işlevselliğin standart arayüz kontrolleriyle de çalıştırılabilmesini ve kullanıcıların yanlışlıkla etkinleştirmeyi önlemek için hareket tabanlı tetikleyicileri devre dışı bırakabilmesini gerektirir.

Görsel sunum için 1.4.3 Contrast Minimum (AA), normal metin için en az 4.5:1, büyük metin için 3:1 oranını gerektirir. Birçok uygulama, giriş alanlarındaki yer tutucu metin, devre dışı bırakılmış düğme etiketleri ve fotoğrafik arka planlar üzerindeki metinler minimumun altında kaldığı için burada hâlâ başarısız oluyor. Geliştiriciler, tüm metinlerin, kontrollerin ve içeriğin hem iOS hem de Android’de Dynamic Type, Kalın Metin, karanlık mod ve sistem düzeyinde kontrast seçenekleriyle çalıştığından emin olmalıdır.

Platforma Özgü Uygulama Rehberi

iOS ve SwiftUI / UIKit

Apple, UIAccessibility API’si ve SwiftUI’de erişilebilirlik değiştiricileri aracılığıyla kapsamlı yerel erişilebilirlik desteği sağlar. VoiceOver desteği için her etkileşimli öğenin anlamlı bir erişilebilirlik etiketi, ipucu ve değeri olmalıdır. Standart UIKit bileşenlerinden türemeyen özel kontroller, VoiceOver’ın bunları doğru şekilde duyurabilmesi için açıkça uygun bir erişilebilirlik özelliğini — .isButton, .isHeader, .isLink — benimsemelidir. Xcode Accessibility Inspector, geliştirme sırasında eksik etiketleri ve özellik uyumsuzluklarını ortaya çıkarmaya yardımcı olabilir.

Dynamic Type için UIKit’in UIFont.preferredFont(forTextStyle:) ve SwiftUI’nin .font(.body) sistem yazı tipleri, kullanıcının tercih ettiği metin boyutuyla otomatik olarak ölçeklenir. scaledValue(for:) kullanmayan sabit point cinsinden yazı tipi boyutları 1.4.4 Resize Text kriterinde başarısız olur. Hedef boyutları için, bir simgenin görsel sunumunu değiştirmeden dokunulabilir alanını UIKit’te contentEdgeInsets veya SwiftUI’de .contentShape() değiştiricisiyle genişletebilirsiniz.

// SwiftUI: görsel boyutu değiştirmeden dokunma alanını genişletme
Image(systemName: "xmark")
    .frame(width: 20, height: 20)
    .contentShape(Rectangle().size(CGSize(width: 44, height: 44)))
    .accessibilityLabel("Close")
    .accessibilityAddTraits(.isButton)

Android ve Jetpack Compose / Views

Android’in erişilebilirliği, TalkBack ve Switch Access’in tükettiği AccessibilityNodeInfo API’si aracılığıyla sunulur. Jetpack Compose’da Modifier.semantics bloğu, içerik açıklamaları, roller, durum açıklamaları ayarlamanıza ve alt öğe semantiklerini birleştirmenize olanak tanır. View tabanlı arayüzlerde ViewCompat.setAccessibilityDelegate(), herhangi bir görünümde erişilebilirlik özelliklerinin programatik olarak değiştirilmesini sağlar.

Dokunma hedefi boyutlandırması için Material Design rehberi minimum 48 × 48 dp önerir. Bir composable veya görünüm görsel olarak daha küçükse, Compose’da (Material3’te tanıtıldı) Modifier.minimumInteractiveComponentSize() kullanarak otomatik olarak 48 dp minimumu uygulayabilir veya eski View sisteminde küçük bir görünümü TouchDelegate içine alarak tıklanabilir alanını genişletebilirsiniz. Metin ölçeklendirmesi için tüm metin boyutlarının, Android’in Ekran ayarlarında belirlenen kullanıcı yazı tipi tercihlerini dikkate alması için dp değil sp (ölçekten bağımsız piksel) cinsinden belirtilmesini sağlayın.

// Jetpack Compose: minimum boyutlu erişilebilir simge düğmesi
IconButton(
    onClick = { onClose() },
    modifier = Modifier
        .minimumInteractiveComponentSize() // 48dp minimumu uygular
        .semantics { contentDescription = "Close dialog" }
) {
    Icon(
        imageVector = Icons.Default.Close,
        contentDescription = null // üst bileşen tarafından tanımlanır
    )
}

Uygulamanızı WCAG 2.2’ye Göre Test Etmek

Mobil erişilebilirliği test etmek, otomatik araçlar ile gerçek yardımcı teknolojilerle yapılan manuel testlerin birleşimini gerektirir. Deque’nin axe DevTools Mobile’ı, Android için Google’ın Accessibility Scanner’ı ve Xcode’daki Apple Accessibility Inspector gibi otomatik araçlar, eksik etiketleri, yetersiz kontrastı ve platform minimumlarının altındaki dokunma hedeflerini yakalayabilir. Ancak otomatik araçlar, gerçek erişilebilirlik sorunlarının yalnızca bir kısmını tespit eder. Karmaşık akışlarda doğru okuma sırasını, anlamlı etiketleri ve mantıklı odak yönetimini doğrulamak için iOS’ta VoiceOver ve Android’de TalkBack ile manuel test zorunludur.

WCAG 2.2’ye özgü kriterler için manuel test özellikle önemlidir. 2.5.8 (Target Size) kriterini test etmek için, iOS Simulator’da fare imleci değil, gerçek parmağınızı kullanarak küçük kontrollerle etkileşim kurmayı deneyin. 3.3.8 (Accessible Authentication) için, oturum açma akışınızın parola alanlarında yapıştırmaya izin verdiğini, parola yöneticilerini (1Password, Bitwarden, sistem anahtarlığı) desteklediğini ve biyometrik kimlik doğrulamayı desteklediğini doğrulayın. 2.4.11 (Focus Not Obscured) için, uygulamanızda tamamen iOS’ta Switch Control veya Android’de Switch Access ile gezinin ve hiçbir odaklanmış öğenin gezinme çubuğunun, modal katmanın veya kayan düğmenin arkasında kaybolmadığından emin olun.

Kapsamlı bir erişilebilirlik test planı, kullanıcının varsayılan yazı tipi boyutunda ve maksimum sistem yazı tipi boyutunda, sırasıyla VoiceOver ve TalkBack etkinleştirilmiş en az iki fiziksel cihazda — bir iPhone ve bir Android cihaz — test yapılmasını içermelidir. Yalnızca simülatörle test, gerçek dünyadaki render farklılıklarını ve yardımcı teknoloji davranışını gözden kaçıracaktır.

Erişilebilirlik kontrollerini CI/CD hattınıza dahil etmeyi düşünün. Hem Espresso (Android) hem de XCUITest (iOS), içerik açıklamaları, özellikler ve etkin durumlar gibi erişilebilirlik özelliklerini doğrulayan otomatik arayüz testleri yazmayı destekler; böylece gerilemeler, üretim denetiminde keşfedilmek yerine kod birleştirilmeden önce yakalanır.

Şimdi Harekete Geçmek İçin Hukuki ve İş Açısından Gerekçeler

Dahil etmenin ahlaki zorunluluğunun ötesinde, mobil erişilebilirlik için iş gerekçesi somuttur. Engellilik alanında liderlik eden şirketler, sektör emsallerine göre 1,6 kat daha fazla gelir ve 2,6 kat daha fazla net gelir elde ediyor. ABD’de engelli kişiler, neredeyse yarım trilyon dolarlık harcanabilir gelire sahip. Ve çevrimiçi engelli tüketicilerin %69’u kullanımı zor buldukları uygulama ve web sitelerini terk ettiğinden, her erişilebilirlik engeli gerçekleşmeyen bir dönüşümdür.

Hukuki risk artıyor. Dijital erişilebilirlik hataları nedeniyle şirketleri hedef alan davalar yıldan yıla artmaya devam ediyor. DOJ’un ADA uyumu için teknik standart olarak WCAG’yi benimsemesi, 2026’daki II. Başlık uygulama son tarihleri ve EAA’nın Haziran 2025’te yürürlüğe girmesi, artık yerel mobil uygulamaları da açıkça kapsayan çok yargı alanlı bir uyum gerekliliği yaratıyor. Önceki bir WCAG 2.1 denetimi, WCAG 2.2 uyumunu otomatik olarak göstermiyor — kimlik doğrulama akışları, form alanları, etkileşimli bileşenler ve odak yönetimi, dokuz yeni başarı kriterine göre yeniden değerlendirilmelidir.

Önemlisi, mobilde erişilebilirlik, lansmandan sonra ucuza sonradan eklenebilecek bir özellik değildir. Yayına alınmış bir uygulamadaki WCAG hatalarını gidermek; güncellenmiş varlıklar, yeniden inşa edilmiş bileşenler, revize edilmiş yerleşimler, yeniden test edilmiş akışlar ve potansiyel olarak yeniden düzenlenmiş kimlik doğrulama sistemleri anlamına gelir. Minimum dokunma hedefi boyutlarını, kontrast belirteçlerini, anlamsal rolleri ve kimlik doğrulama kalıplarını bileşen düzeyinde zorunlu kılan tasarım sistemlerine ve bileşen kütüphanelerine en baştan WCAG 2.2 uyumunu yerleştiren ekipler, erişilebilir olmayan bir uygulamayı lansman sonrası düzeltmeye kıyasla maliyetin çok küçük bir kısmını öder.

Temel Çıkarımlar

• WCAG 2.2, yerel iOS ve Android uygulamaları için geçerlidir. W3C’nin WCAG2Mobile rehberi, her A ve AA seviye başarı kriterini mobil ekranlara ve görünümlere eşler; bu da yalnızca mobil web sitenizin değil, yerel uygulamanızın da kapsam dahilinde olduğu anlamına gelir.
• Dokunma hedefi boyutu, mobil denetimlerde en yaygın yeni hata türüdür. WCAG 2.2’nin 24 × 24 minimumu tabandır; Apple 44 × 44 pt, Google 48 × 48 dp önerir. Simgeyi görsel olarak büyütmek yerine, tıklanabilir alanı dolgu ve platforma özgü API’lerle genişletin.
• Parola alanlarında yapıştırmayı engellemek, muhtemelen 3.3.8 Accessible Authentication’ı ihlal eder. Her iki platformda da oturum açma akışlarının bilişsel erişilebilirlik gerekliliklerini karşılamak için sistem anahtarlıklarını, parola yöneticilerini, biyometriyi ve OTP otomatik doldurmayı destekleyin.
• VoiceOver ve TalkBack ile manuel test vazgeçilmezdir. Otomatik araçlar erişilebilirlik sorunlarının yalnızca bir kısmını yakalar. Tüm kritik kullanıcı yolculuklarında, yardımcı teknolojiler etkin, maksimum yazı tipi boyutuna ayarlanmış fiziksel cihazlarda test yapın.
• Erişilebilirliği tasarım sisteminize şimdi, lansmandan önce dahil edin. Erişilebilir olmayan uygulamaları lansman sonrası düzeltmek, erişilebilir bileşen standartlarını ilk günden itibaren uygulamaya koymaktan çok daha pahalıdır. DOJ, HHS ve EAA uygulama takvimleri 2025–2026’da gelirken, düşük maliyetli uyum çalışmaları için pencere kapanıyor.