2026'da Android'de erişilebilirlik: gerçekten uygulanan bir TalkBack ve Compose semantiği kontrol listesi

Android’de erişilebilirlik genellikle yayın öncesi bir kontrol listesi maddesi olarak ele alınır, UI “bittikten” sonra araya sıkıştırılır. Bu sıralama tersine dönüktür ve bunu belli eder: semantik düşünülmeden kurulan bir ekranın sonradan düzeltilmesi saatler alırken, baştan semantikle kurulan aynı ekranın neredeyse hiç ek maliyeti yoktur. Bu, gerçekten uyguladığım kontrol listesi — bir politika belgesi değil, Compose UI yazarken yaptığım şeylerin bir listesi, artı yayınlanmadan önceki test turu.

Sonradan düzeltmek neden pahalı, baştan kurmak neden değil

Android’in ekran okuyucusu TalkBack, pikselleri okumaz — Compose’un UI’ınızla birlikte ürettiği semantik ağacı okur. Bu ağacı bir ekran yazarken hiç düşünmezseniz, TalkBack sonunda ham uygulama detaylarını okur: sadece ikonlu bir düğme “Düğme” olarak duyurulur, dekoratif bir görsel “Görsel” olarak duyurulur ve üç ayrı composable’dan oluşan bir satır tek bir cümle yerine üç ayrı durak olarak duyurulur. Bunu sonradan düzeltmek, her composable’a geri dönüp “bu aslında ne söylemeli” diye sormak demektir — ki bu, aynı soruyu ilk seferinde sormaktan çok daha yavaştır.

Çözüm, semantiği Modifier zincirinin sonuna eklenen bir ek düşünce değil, bileşenin API’sinin bir parçası olarak ele almaktır.

Kontrol listesi

1. Metin dışı her kontrolün bir contentDescription’ı vardır — ya da hiç yoktur

Bir düğmenin görünür metni varsa gereksiz bir açıklama eklemeyin — TalkBack zaten metni okur ve tekrar eden bir açıklama iki kez okunmasına neden olur. Düğme sadece ikonluysa açıklama zorunludur:

IconButton(onClick = { onDelete(item.id) }) {
    Icon(
        imageVector = Icons.Default.Delete,
        contentDescription = stringResource(R.string.delete_item, item.name)
    )
}

Tamamen dekoratif görseller açıkça contentDescription = null alır. Hiç açıklaması olmayan bir görsel yine de “etiketsiz görsel” olarak duyurulur, ki bu sessizlikten daha kötüdür.

2. İlgili içeriği mergeDescendants ile grupla

Başlık, alt başlık ve bir rozet içeren bir kart, varsayılan olarak üç ayrı TalkBack durağı olarak okunur — bu da tek bir satırı duymak için üç kaydırma demektir. Grubu, tek bir birim olarak duyurulacak şekilde sarın:

Row(
    modifier = Modifier.semantics(mergeDescendants = true) {}
) {
    Text(title)
    Text(subtitle)
    Badge { Text(status) }
}

Bunu, TalkBack’i açıp ekranı bir kez kaydırarak test edin. Tek bir mantıksal satır birden fazla kaydırma gerektiriyorsa birleştirilmesi gerekir.

3. Dokunma hedefleri ikonun görsel boyutu değil, 48dp’dir

Dolgusuz 24dp’lik bir ikon, 24dp’lik bir dokunma hedefidir — bu hem erişilebilirlik yönergelerini hem de azalmış el becerisi olan biri için temel kullanılabilirliği başarısız kılar. Güncel Compose’daki Modifier.minimumInteractiveComponentSize(), manuel dolgu hesabı yapmadan bunu halleder — bunu incelemede sıkışık hissettiren ikonlara değil, dokunulabilir her ikona uygulayın.

4. Durumu yalnızca renkle iletmeyin

Geçersiz bir alan etrafındaki kırmızı çerçeve, renk körü bir kullanıcı için görünmez ve TalkBack kullanıcısı için duyurulmaz. Yalnızca renkle verilen her sinyali metin veya ikon değişikliğiyle eşleştirin: alanın altında bir hata mesajı, etiketin yanında bir hata ikonu. Bu, görme engeli olmayan bir kullanıcı için de daha iyi bir UX’tir — yalnızca renk, bir kelimeden daha fazla dikkat gerektirir.

5. Tıklama olmadan değişen içerik için canlı bölgeler

Kullanıcı bir tutar yazdıktan sonra bir toplam güncelleniyorsa, composable bir canlı bölge olarak işaretlenmedikçe TalkBack bunu fark etmez:

Text(
    text = "Toplam: $formattedTotal",
    modifier = Modifier.semantics { liveRegion = LiveRegionMode.Polite }
)

Polite, mevcut duyurunun bitmesini bekler; Assertive araya girer. Assertive’i tutumlu kullanın — anlık dikkat gerektiren bir hata için, çalışan bir toplam için değil.

Test turu

Kod incelemesi muhtemelen bunun ancak yarısını yakalar, çünkü bu sorunların çoğu ancak ekran okuyucu açıkken belli olur. Bir ekranı yayınlamadan önce üç kontrol yapıyorum:

1. TalkBack ile, ekranı baştan sona kaydırarak, ekran kapalıyken sadece dinleyerek. Bir kontrolün ne yaptığını sadece duyurudan anlayamıyorsam, daha iyi bir açıklamaya ihtiyacı var demektir.
2. Accessibility Scanner (Google’ın bağımsız uygulaması), dokunma hedefi boyutu ve kontrast oranı için — ikisini de otomatik olarak işaretler ve tam composable’ı gösterir.
3. Sistem ayarlarında %200 yazı tipi ölçeği. Bu ölçekte kırpılan, üst üste binen ya da kesilen metin bir kenar durumu değil, bir hata — gerçek kullanıcıların anlamlı bir kısmı büyütülmüş yazı tipi boyutlarını kalıcı olarak kullanıyor.

Bu bazı uygulamalar için diğerlerinden daha önemli. İlaç hatırlatıcı uygulaması OldSchool, daha büyük yazı tipi ölçeklerinin ve ekran okuyucuların kenar durumu olmadığı, medyana daha yakın olduğu yaşlı bir kullanıcı kitlesine yöneliyor. Kontrol listesini bileşen kütüphanesine bir kez inşa etmek, uygulama büyüdükçe bunu ekran ekran yeniden türetmek zorunda kalmamamı sağladı.

Sonuç

Bir projenin sonunda yapılan erişilebilirlik çalışması pahalıdır çünkü düzelticidir — birinin boşluğu fark etmesi, sonra geri dönüp her ekranı tek tek yamalaması gerekir. Her composable’ı yazmanın parçası olarak yapılan erişilebilirlik çalışması neredeyse bedavadır, çünkü sorular (“bu ne olarak duyuruluyor,” “bu bir durak mı üç durak mı,” “dokunma hedefi gerçek mi”) koda zaten bakarken saniyeler içinde cevaplanır. Kontrol listesini yayın haftası yangın tatbikatı değil, yeni ekranlar için bir alışkanlık olarak ele alın; o zaman zaten bir kontrol listesi olmaktan çıkar.