Mobil Uygulama Erişilebilirliği Nasıl Test Edilir? VoiceOver ve TalkBack Rehberi

Bu rehberde Talha Aslan ve ekibi olarak genel bir erişilebilirlik anlatısı yapmıyoruz. Odak tek bir soru: elinizdeki uygulama ekran okuyucuyla gerçekten kullanılabilir durumda mı? Bu yüzden her bölüm bir kontrol listesi, bir karar tablosu ya da numaralı test adımlarıyla bitiyor. Kod örneği vermiyoruz; ürün sahibi, tasarımcı ve test ekibi aynı listeyi kullanabilsin diye kavram düzeyinde kalıyoruz. Web sitesi tarafındaki standartları merak ediyorsanız web erişilebilirliği ve WCAG yazımız o konuyu ayrıca anlatıyor.

Ekran okuyucu bir uygulamayı nasıl okur?

Ekran okuyucu, ekrandaki her öğeyi sırayla seslendiren bir sistem hizmetidir. iPhone ve iPad'de bu hizmetin adı VoiceOver, Android'de TalkBack'tir. Kullanıcı parmağını sağa ya da sola kaydırarak bir sonraki öğeye geçer, çift dokunarak seçili öğeyi etkinleştirir. Android geliştirici belgeleri bu iki yolu doğrusal gezinme ve dokunarak keşfetme olarak tarif eder.

Ekran okuyucu her öğe için üç bilgi seslendirir: öğenin adı (etiketi), türü (düğme, anahtar, başlık gibi) ve varsa durumu (seçili, kapalı gibi). Dolayısıyla uygulamanızın bu üç bilgiyi doğru vermesi gerekir. Görsel olarak çok net görünen bir simge, etiketi yoksa ekran okuyucuda yalnızca "düğme" diye okunur. Kullanıcı bu düğmenin ne yaptığını tahmin etmek zorunda kalır. Erişilebilirlik testinin özü budur: uygulamayı gözle değil kulakla kullanmak.

VoiceOver'ı test için nasıl açarsınız?

VoiceOver'ı iPhone'un Ayarlar uygulamasındaki Erişilebilirlik bölümünden açarsınız. İlk kullanımda hareketler farklı geldiği için önce kısa bir alıştırma yapın. Test sırasında işinizi kolaylaştıracak adımlar şunlardır:

1. Erişilebilirlik kısayolunu VoiceOver olarak ayarlayın; böylece yan tuşa üç kez basarak açıp kapatabilirsiniz.
2. Bir ekranda tek parmakla sağa kaydırarak her öğeyi sırayla dinleyin.
3. Çift dokunarak seçili öğeyi etkinleştirin ve sonucun seslendirilip seslendirilmediğine bakın.
4. Rotor denen döndürme hareketiyle başlıklar arasında gezinmeyi deneyin; başlık işaretlenmemişse bu gezinme çalışmaz.
5. Ekran perdesini açarak ekranı karartın ve testi gerçekten görmeden yapın.

Son adım en öğreticisidir. Ekranı görürken sesli çıktıyı tamamlarsınız; ekran kararınca kullanıcının yaşadığı belirsizliği birebir hissedersiniz. Apple'ın İnsan Arayüzü Yönergeleri erişilebilirlik bölümü bu deneyimin tasarım tarafını, etiket, yazı boyutu ve renk konularında ayrıntılı anlatır.

TalkBack'i test için nasıl açarsınız?

Android geliştirici belgelerindeki erişilebilirlik testi rehberine göre TalkBack'i cihazın Ayarlar uygulamasında Erişilebilirlik bölümünden, TalkBack seçeneğini açarak etkinleştirirsiniz. İlk açılışta bir eğitim başlar; bunu atlamayın, çünkü hareketleri öğrenmeden yaptığınız test yanıltıcı olur.

Belgeler ayrıca test eden kişi için iki yardımcı ayar anlatır. TalkBack ayarlarındaki geliştirici seçeneklerinde günlük çıktı düzeyini ayrıntılı yapabilir ve konuşma çıktısını ekranda gösterme seçeneğini açabilirsiniz. Böylece TalkBack'in ne söylediğini hem duyar hem de yazılı görürsünüz. Bu ayar, hata raporu yazarken çok işe yarar; çünkü "düğme yanlış okunuyor" demek yerine tam olarak ne okunduğunu yazarsınız.

TalkBack ile test sırasında belgelerin önerdiği soruları sorun: her öğenin sesli karşılığı içeriğini ya da amacını anlatıyor mu, seslendirmeler kısa mı yoksa gereksiz uzun mu, ana iş akışını rahatça tamamlayabiliyor musunuz, her öğeye kaydırarak ulaşabiliyor musunuz ve geçici uyarılar sesli okunuyor mu?

Mobil uygulama erişilebilirliği için ekran okuyucu etiketlerini nasıl yazarsınız?

Etiket, ekran okuyucunun bir öğe için söylediği addır. İyi etiket kısa, benzersiz ve amaca odaklıdır. Android belgeleri birkaç net kural koyar: açıklama görsel ayrıntıyı değil etkileşimin amacını ve sonucunu anlatmalı; öğenin türünü etikete yazmamalısınız, çünkü sistem türü zaten okur. Örneğin gönderme düğmesinin etiketi "Gönder düğmesi" değil, "Gönder" olmalıdır.

Ayrıca her etiket benzersiz olmalıdır. Bir listede on tane "Sil" düğmesi varsa, kullanıcı hangisinin hangi kaydı sildiğini bilemez. Bu yüzden etikete kaydın adını ekleyin: "İstanbul adresini sil" gibi. Yalnızca süs amaçlı görselleri ise ekran okuyucudan gizleyin; aksi halde kullanıcı anlamsız öğeler arasında vakit kaybeder. Aşağıdaki kontrol listesiyle etiketleri gözden geçirin:

• Simge düğmelerin hepsinin etiketi var mı?
• Etiketler eylemi anlatıyor mu, görüntüyü değil mi?
• Etikette "düğme", "simge" gibi tür bilgisi tekrar ediyor mu?
• Liste öğelerindeki tekrar eden düğmeler benzersiz mi?
• Süs görselleri ekran okuyucudan gizli mi?
• Form alanlarının etiketi, alanın üstündeki görünür yazıyla aynı anlamı veriyor mu?

Okuma sırası ve odak neden bu kadar önemli?

Ekran okuyucu öğeleri belirli bir sırayla okur. Bu sıra görsel düzenle uyumlu değilse kullanıcı ekranın mantığını kuramaz. Örneğin bir ürün kartında önce fiyat, sonra ürün adı, en son da görsel okunuyorsa kullanıcı neyin fiyatını duyduğunu bilemez. Android belgeleri Play Console ön yayın raporunda bu tür sorunları "uygulama" başlığı altında, mantıksal düzenle uyuşmayan gezinme sırası olarak listeler.

Odak yönetimi de aynı ölçüde önemlidir. Bir pencere açıldığında odak o pencereye geçmeli, pencere kapanınca da kullanıcının geldiği yere dönmelidir. Ayrıca bir hata mesajı belirdiğinde ekran okuyucu bunu duyurmalıdır. Duyurmazsa kullanıcı formu neden gönderemediğini hiç öğrenemez. Örnek senaryo: kullanıcı bir randevu formunda tarih seçmek için takvim penceresini açıyor, ancak odak arka plandaki forma takılı kalıyor. Bu durumda kullanıcı takvimin açıldığını hiç duymuyor ve randevuyu tamamlayamıyor. Kısacası okuma sırası ve odak, görsel tasarımda göremediğiniz ama ekran okuyucu kullanıcısının her saniye hissettiği bir katmandır.

Bunu test etmek için şu üç soruyu sorun: okuma sırası ekranı yukarıdan aşağı mantıklı biçimde izliyor mu, yeni açılan içerik odağı alıyor mu, kapanan içerik odağı doğru yere bırakıyor mu?

Dokunma hedefi ne kadar büyük olmalı?

Dokunma hedefi, bir düğmenin ya da bağlantının parmakla dokunulabilen alanıdır. Küçük hedefler yalnızca motor engeli olan kişileri değil, yürürken telefon kullanan herkesi zorlar. Android'in erişilebilir uygulama rehberi her etkileşimli öğe için en az 48dp x 48dp dokunma alanı önerir ve daha büyüğünün daha iyi olduğunu belirtir. Hazır bileşenlerin çoğu bu ölçüyü kendiliğinden sağlar; ancak özel çizdiğiniz öğelerde boyutu sizin ayarlamanız gerekir.

Apple tarafında da İnsan Arayüzü Yönergeleri kontrollerin rahatça dokunulabilecek büyüklükte ve aralıkta olmasını ister; güncel ölçüyü yönergelerin kendisinden kontrol edin. Görsel olarak küçük bir simge kullanmak istiyorsanız sorun değil: simgeyi küçük tutup çevresindeki dokunma alanını büyütebilirsiniz. Ayrıca iki hedefi birbirine çok yakın koymayın; yanlışlıkla diğerine dokunmak, özellikle silme ya da ödeme gibi işlemlerde ciddi sorun yaratır. Başparmağın rahat eriştiği alanlar için thumb zone yazımız yerleşim tarafını anlatıyor.

Dinamik yazı boyutunu nasıl test edersiniz?

Pek çok kullanıcı telefonunda yazı boyutunu büyütür. iOS'ta bu özelliğin adı Dynamic Type, Android'de yazı tipi boyutu ve ekran boyutu ayarlarıdır. Uygulamanız sistem yazı stillerini kullanıyorsa yazılar bu ayara göre büyür. Sabit boyutlu yazı kullandıysanız ayar hiçbir şey değiştirmez ve kullanıcı küçük yazıyla baş başa kalır.

Testi şu adımlarla yaparsınız:

1. Cihazın yazı boyutu ayarını en büyük değere getirin.
2. Uygulamanın her ana ekranını açın ve yazıların büyüdüğünü doğrulayın.
3. Kesilen, üst üste binen ya da düğmeden taşan yazı var mı bakın.
4. Uzun bir metnin kaydırılarak tamamen okunabildiğini kontrol edin.
5. Yatay ekranda aynı kontrolü tekrarlayın.

En sık rastladığımız sorun, sabit yükseklikteki düğmelerde büyüyen yazının kesilmesidir. Bu yüzden tasarım aşamasında düğme ve kartların yazıya göre uzayabilmesini planlayın.

Renk kontrastı hangi oranda olmalı?

Kontrast, yazı rengi ile arka plan rengi arasındaki parlaklık farkıdır. Android rehberi net bir eşik verir: 18sp'den küçük yazılar ya da 14sp'den küçük kalın yazılar için en az 4.5:1, diğer tüm yazılar için en az 3:1 kontrast oranı önerir. Bu oranlar web tarafındaki WCAG eşikleriyle de uyumludur.

Kontrast yalnızca yazı için değil, anlam taşıyan simgeler ve form alanı kenarlıkları için de önemlidir. Ayrıca bilgiyi yalnızca renkle vermeyin. Örneğin hatalı alanı sadece kırmızıya boyamak, renk ayırt etmekte zorlanan kişi için hiçbir şey ifade etmez. Bunun yerine renkle birlikte bir simge ve kısa bir hata metni kullanın. Kontrol listeniz şöyle olsun:

• Gövde metni ve küçük etiketler en az 4.5:1 mi?
• Büyük başlıklar ve büyük yazılar en az 3:1 mi?
• Pasif düğmeler hâlâ okunabiliyor mu?
• Hata, uyarı ve başarı durumları renk dışında bir işaret de taşıyor mu?
• Koyu temada aynı oranları koruyor musunuz?

Mobil uygulama erişilebilirliği testinde hangi araçları kullanabilirsiniz?

Elle test her zaman ilk adımdır, ancak araçlar gözden kaçanları yakalar. Aşağıdaki karar tablosu hangi aracın neye yaradığını özetler:

Android belgeleri, Play Console'a yüklediğiniz sürüm için oluşan ön yayın raporunda erişilebilirlik sekmesinin sorunları dokunma hedefi, düşük kontrast, içerik etiketi ve uygulama başlıklarıyla gruplandığını anlatır. Bu rapor ücretsiz bir ikinci göz gibidir; yine de elle testin yerini tutmaz.

Teste hangi ekranlardan başlamalısınız?

Uygulamanızda onlarca ekran olabilir; hepsini aynı anda test etmeye çalışmak ekibi yorar ve işi yarıda bırakır. Bu yüzden önce kullanıcının uygulamayı açma nedenini oluşturan akışları seçin. Çoğu uygulamada bu sıralama şöyle olur:

1. Kayıt ve giriş ekranları, çünkü kullanıcı buradan geçemezse geri kalan her şey erişilemez kalır.
2. Ana sayfa ve gezinme menüsü.
3. Arama ve listeleme ekranları.
4. Ürün, hizmet ya da içerik detay ekranı.
5. Sepet, ödeme ya da form gönderme adımları.
6. Ayarlar, profil ve destek ekranları.

İlk dört maddeyi bir hafta içinde test etmek, çoğu zaman en kritik sorunların büyük kısmını ortaya çıkarır. Ardından bulduğunuz ortak sorunları tasarım sistemi düzeyinde düzeltirseniz, geri kalan ekranlar da kendiliğinden iyileşir. Örneğin bir kart bileşeninin okuma sırasını bir kez düzeltmek, o kartı kullanan bütün listeleri birden düzeltir.

Bir ekranı adım adım nasıl test edersiniz?

Her ekran için aynı sırayı izlemek, testi tekrarlanabilir kılar. Ekibimizin kullandığı sıra şöyledir:

1. Ekran okuyucuyu açın ve ekranın başlığının ilk okunan öğe olduğunu doğrulayın.
2. Sağa kaydırarak bütün öğeleri dinleyin; etiketsiz, anlamsız ya da tekrar eden öğeleri not edin.
3. Ana işlemi yalnızca sesle tamamlayın: örneğin bir formu doldurup gönderin.
4. Hatalı bir değer girin ve hata mesajının seslendirildiğini kontrol edin.
5. Bir pencere ya da alt sayfa açın; odağın oraya geçip geçmediğine bakın.
6. Yazı boyutunu en büyük değere getirip ekranı tekrar kontrol edin.
7. Kontrastı bir araçla ölçün ve dokunma hedeflerini gözden geçirin.
8. Bulduğunuz her sorunu ekran adı, öğe, beklenen ve duyulan seslendirme ile kaydedin.

Bu sırayı bir test şablonuna çevirirseniz, her yeni sürümde aynı ekranları birkaç dakikada kontrol edebilirsiniz. Böylece erişilebilirlik bir kerelik proje olmaktan çıkar ve sürüm sürecinin parçası olur. Ayrıca her testte aynı cihazı ve aynı ayarları kullanmaya özen gösterin; böylece iki sürüm arasındaki farkı daha net görürsünüz.

Erişilebilirlik sorunlarını kendi ekibinizle çözemezseniz ne yaparsınız?

Testi yaptınız ve uzun bir sorun listesi çıktı. Bu noktada çoğu ekibin karşılaştığı durum şudur: sorunların bir kısmı tasarım sisteminden, bir kısmı özel bileşenlerden, bir kısmı da uygulamanın genel yapısından kaynaklanır. Etiket eklemek kolaydır; ama sabit yükseklikli bir tasarım sistemini dinamik yazıya uyarlamak ya da odak yönetimini baştan kurmak, mimari bir iştir.

Önceliği belirlemek için önce ana iş akışlarını düzeltin: giriş, arama, sepete ekleme, ödeme, form gönderme. Kullanıcı bu akışları tamamlayamıyorsa diğer iyileştirmeler anlamını yitirir. Bu iş kendi ekibinizin kapasitesini aşıyorsa, mobil uygulama geliştirme projelerimizde erişilebilirliği tasarım sisteminden test şablonuna kadar baştan kuruyoruz; böylece her yeni ekran aynı kurallarla doğar. Uygulamanız çapraz platform bir yapıdaysa React Native yazımız iki platformun ortak ve ayrı yönlerini anlatıyor.

Hareketler, animasyon ve zaman sınırları erişilebilirliği nasıl etkiler?

Bazı işlemler yalnızca karmaşık hareketlerle yapılabiliyorsa, ekran okuyucu ya da anahtar erişimi kullanan kişiler bu işlemlere ulaşamaz. Örneğin bir listede yalnızca sola kaydırarak silme yapılabiliyorsa, aynı işlemi bir menüden ya da özel eylemden de sunmanız gerekir. Android belgeleri anahtar erişimi testinde de dokunmatik hareketle yapılan her işlevin seçilebilir bir kontrol ya da özel eylem olarak sunulup sunulmadığını sormanızı önerir.

Animasyon tarafında, sistemde hareketi azaltma ayarı açık olan kullanıcıya büyük geçiş animasyonları göstermeyin. Ayrıca kendiliğinden kaybolan bildirimler ekran okuyucu kullanıcısına yetişmeyebilir; önemli mesajları kalıcı tutun ya da yeterli süre tanıyın. Zaman sınırlı işlemlerde, örneğin bir doğrulama kodunda, kullanıcıya süreyi uzatma imkânı verin. Kısacası her etkileşimin, hızlı ve hassas parmak hareketine ihtiyaç duymayan bir yolu olmalıdır.

Formlar ve hata mesajları nasıl erişilebilir olur?

Formlar, mobil uygulamalarda erişilebilirlik sorunlarının en yoğun olduğu yerdir. İlk kural: her alanın görünür ve kalıcı bir etiketi olmalı. Yalnızca alanın içindeki silik ipucu yazısına güvenmeyin; kullanıcı yazmaya başlayınca bu yazı kaybolur ve ekran okuyucu her zaman doğru okumayabilir.

İkinci kural: hata mesajı hem görsel hem sesli olmalı. Kullanıcı formu gönderdiğinde hata varsa odak ilk hatalı alana gitmeli ve mesaj seslendirilmelidir. Mesajın kendisi de çözüm söylemeli: "Geçersiz giriş" yerine "Telefon numarası 10 haneli olmalı" gibi. Üçüncü kural: klavye türünü alana uygun seçin; e-posta alanında e-posta klavyesi, telefon alanında rakam klavyesi açılsın. Ayrıca otomatik doldurma desteği, motor engeli olan kullanıcıların yazma yükünü belirgin biçimde azaltır. Formlarda kullanılabilirliği gerçek kullanıcıyla ölçmek isterseniz beş kullanıcıyla kullanılabilirlik testi yazımız pratik bir yöntem sunuyor.

Çevrimdışı ve durum mesajlarını ekran okuyucuya nasıl duyurursunuz?

Uygulamada görsel olarak beliren her durum değişikliği, ekran okuyucu kullanıcısı için de duyulabilir olmalıdır. İlerleme göstergesi, "kaydedildi" bildirimi, bağlantı koptu uyarısı gibi mesajlar sessiz kalırsa kullanıcı uygulamanın donduğunu sanabilir. Android belgeleri TalkBack testinde geçici uyarıların sesli okunup okunmadığını özellikle kontrol etmenizi önerir.

Bu konu özellikle internet bağlantısının gidip geldiği uygulamalarda kritiktir. Kayıtların cihazda mı tutulduğunu yoksa sunucuya mı gittiğini gösteren durum etiketleri, ekran okuyucu tarafından da okunmalıdır. Kardeş yazımız uygulamada çevrimdışı mod tasarımı bu durum etiketlerini nasıl kurgulayacağınızı anlatıyor. Erişilebilirlik tarafında kural basittir: ekranda gördüğünüz her önemli değişiklik, sesli olarak da duyulmalıdır.

Görseller, grafikler ve videolar nasıl erişilebilir olur?

Bilgi taşıyan her görselin bir metin karşılığı olmalıdır. Ürün fotoğrafı için kısa bir açıklama yeterlidir; ancak bir grafik ya da tablo görseli bilgi veriyorsa, ekran okuyucu kullanıcısının da aynı bilgiye ulaşması gerekir. Bu yüzden grafiğin yanında ana sonucu metin olarak yazın ya da veriyi okunabilir bir liste halinde sunun. Örneğin "Bu ay satışlar geçen aya göre arttı" gibi tek bir cümle, ekran okuyucu kullanıcısı için bütün grafikten daha değerlidir.

Video ve ses içeriklerinde altyazı, işitme engeli olan kullanıcılar için temel şarttır. Ayrıca videonun kendiliğinden sesli başlaması, ekran okuyucunun sesini bastırır ve kullanıcıyı zor duruma sokar. Bu nedenle videoyu kullanıcı başlatsın ve oynatma kontrollerinin etiketi olsun. Sosyal medya tarafındaki alt metin ve altyazı pratikleri için sosyal medyada erişilebilirlik yazımız benzer ilkeleri anlatıyor. Kısacası görsel bir bilgiyi yalnızca görsel olarak bırakmayın.

iOS ve Android arasında erişilebilirlik testinde fark var mı?

İlkeler iki platformda da aynıdır: her öğenin bir adı, türü ve durumu olmalı; yazı büyüyebilmeli; kontrast yeterli olmalı. Ancak uygulama ayrıntıları farklıdır. Hareketler birbirine benzese de aynı değildir; örneğin VoiceOver'daki rotor ile TalkBack'teki okuma kontrolleri farklı çalışır. Bu yüzden ekibinizde test yapan kişinin her iki ekran okuyucuyu da ayrı ayrı öğrenmesi gerekir.

Ayrıca aynı kod tabanından çıkan bir uygulama bile iki platformda farklı seslendirebilir. Çapraz platform bir çatı, etiketi bir platformda doğru, diğerinde eksik aktarabilir. Dolayısıyla "Android'de test ettik, iOS'ta da aynıdır" varsayımı güvenli değildir. Her sürümde ana iş akışlarını iki platformda da en az bir kez sesle tamamlayın. Bunun yanında yazı boyutu ayarlarının iki sistemde farklı adlarla ve farklı aralıklarla çalıştığını unutmayın; en büyük değerde test etmek, iki tarafta da en çok sorun çıkaran senaryodur.

Erişilebilirlik testini sürüm sürecine nasıl eklersiniz?

Erişilebilirliği bir kerelik denetim olarak yapan ekipler, birkaç sürüm sonra aynı sorunlarla tekrar karşılaşır. Çünkü her yeni ekran ve bileşen yeni bir risk getirir. Bu nedenle testi sürüm sürecinin sabit bir adımına çevirin. Önerdiğimiz düzen şöyledir:

1. Tasarım aşamasında her yeni bileşen için kontrast, dokunma hedefi ve büyük yazı davranışını kontrol edin.
2. Geliştirme sırasında her etkileşimli öğeye etiket eklemeyi tamamlanma şartı yapın.
3. Test aşamasında ana iş akışlarını iki ekran okuyucuyla da sesle tamamlayın.
4. Yayından önce ön yayın raporu ve tarayıcı araçlarındaki yeni uyarıları inceleyin.
5. Yayından sonra kullanıcı geri bildirimlerinde erişilebilirlik konulu talepleri ayrı etiketleyin.

Bu düzen ilk birkaç sürümde biraz zaman alır, ancak ekip alıştıkça testin süresi kısalır. Üstelik erken yakaladığınız bir sorun, yayından sonra fark ettiğiniz bir sorundan her zaman daha ucuzdur.

Bulduğunuz sorunları nasıl raporlamalısınız?

İyi bir hata raporu, geliştiricinin sorunu tekrar üretip hızlıca düzeltmesini sağlar. Erişilebilirlik hatalarında "ekran okuyucu çalışmıyor" gibi genel bir not işe yaramaz. Bunun yerine her kayıtta şu alanları doldurun: platform ve ekran okuyucu, ekran adı, öğe, beklenen seslendirme, duyulan seslendirme, kullanıcıya etkisi ve önerilen çözüm. Örneğin: "Android, TalkBack, sepet ekranı, çöp kutusu simgesi; beklenen 'Ürünü sepetten çıkar', duyulan 'Düğme'; kullanıcı ürünü çıkaramıyor."

Ayrıca sorunları etkisine göre sıralayın. Bir iş akışını tamamen engelleyen hata en üstte yer almalı, kozmetik sorunlar ise sonraya kalabilir. Böylece sınırlı geliştirme süresini en çok kullanıcıyı etkileyen konulara ayırırsınız. TalkBack'in konuşma çıktısını ekranda gösterme ayarı bu raporları yazarken büyük kolaylık sağlar.

Avrupa Erişilebilirlik Yasası mobil uygulamaları etkiler mi?

Avrupa Birliği'nin Avrupa Erişilebilirlik Yasası (European Accessibility Act, kısaca EAA), belirli ürün ve hizmetler için erişilebilirlik şartları koyar. Yasa kapsamındaki hizmetler arasında e-ticaret ve bankacılık gibi tüketici hizmetleri bulunur ve bu hizmetlerin mobil uygulamaları da kapsam içinde değerlendirilir. Dolayısıyla AB'deki tüketicilere uygulama üzerinden hizmet sunan bir işletme, mobil uygulama erişilebilirliği konusunu yalnızca iyi niyetli bir iyileştirme olarak değil, olası bir yükümlülük olarak da ele almalıdır.

Kapsam, muafiyetler ve ülkelere göre uygulama ayrıntıları değişebilir; güncel durumu resmi kaynaklardan kontrol edin. Yasanın web sitelerine etkisini ve kapsamı nasıl değerlendireceğinizi Avrupa Erişilebilirlik Yasası yazımızda ayrıntılı anlattık. Bu bölüm hukuki danışmanlık değildir; kendi durumunuz için hukuk danışmanınızla çalışın.

Erişilebilirlik sonradan eklenirse neden pahalıya mal olur?

Erişilebilirliği yayından sonra eklemeye çalışan ekipler aynı sorunla karşılaşır: sorunların çoğu tek bir ekranda değil, tasarım sisteminin kendisindedir. Sabit yükseklikli düğmeler, renk paleti, özel bileşenler ve okuma sırası her ekranda tekrar eder. Bu yüzden bir hatayı düzeltmek çoğu zaman onlarca ekranı birden değiştirmek demektir.

Bu birikim, yazılımdaki teknik borcun bir türüdür. Kardeş yazımız yazılım projesinde teknik borç bu kavramı ve nasıl yöneteceğinizi anlatıyor. Erişilebilirlikte borcu azaltmanın yolu basittir: tasarım sistemine kontrast, yazı boyutu ve dokunma hedefi kurallarını baştan yazın, her yeni bileşeni ekran okuyucuyla test etmeden kabul etmeyin. Üstelik bu kurallar yalnızca engelli kullanıcılara değil, güneş altında telefon kullanan ya da tek eliyle işlem yapan herkese fayda sağlar.

Mobil uygulama erişilebilirliği için son kontrol listesi nedir?

Rehberin özetini, her sürümden önce işaretleyebileceğiniz bir listeye çevirdik:

• VoiceOver ve TalkBack ile ana iş akışları yalnızca sesle tamamlanabiliyor mu?
• Her etkileşimli öğenin kısa, benzersiz ve amaca odaklı bir etiketi var mı?
• Okuma sırası görsel düzenle uyumlu mu, odak açılan içeriğe geçiyor mu?
• Dokunma hedefleri platform önerilerine uyuyor mu?
• En büyük yazı boyutunda kesilen ya da taşan metin var mı?
• Kontrast oranları eşikleri karşılıyor mu, bilgi yalnızca renkle mi veriliyor?
• Kaydırma gibi hareketlerin alternatif bir yolu var mı?
• Ekran okuyucu hata ve durum mesajlarını seslendiriyor mu?
• Ön yayın raporu ve tarayıcı araçlarındaki uyarıları incelediniz mi?

Bu listeyi her sürüm öncesi kullanırsanız erişilebilirlik bir kampanya değil, alışkanlık olur. Uygulamanızı baştan erişilebilir kurmak ya da mevcut uygulamanızı bu listeye göre elden geçirmek istiyorsanız mobil uygulama yaptırmak sayfamızda nasıl çalıştığımızı bulabilirsiniz.