Barrierefreies Kotlin: Code, der niemanden ausschließt

Warum Accessibility in Kotlin eine Superkraft ist – und kein lästiges Ankreuzfeld

Stell dir vor: Du hast eine coole App in Kotlin geschrieben. Schönes Material Design, flüssige Animationen, reaktive Streams. Du bist stolz auf deinen Code. Aber dann stellt sich heraus, dass eine Person mit Sehschwäche den „Kaufen“-Button nicht drücken kann, weil TalkBack ihn als „nicht beschrifteter Button“ vorliest. Oder ein Nutzer mit Zittern in den Händen verfehlt den winzigen Schalter.

Accessibility (Barrierefreiheit) ist keine langweilige Bürokratie. Es geht darum, dass dein Kotlin-Code für jeden funktioniert. Laut WHO haben über eine Milliarde Menschen eine Behinderung. Sie zu ignorieren bedeutet, Zielgruppe zu verlieren – und ehrlich gesagt, ein schlechter Entwickler zu sein.

In diesem Artikel zeigen wir dir, wie du barrierefreien Kotlin-Code schreibst – ohne Schmerz. Ohne Tonnen von Boilerplate-Code. Mit lebendigen Beispielen, die du direkt kopieren und einfügen kannst.

Grundprinzipien: ContentDescription – dein bester Freund

Der häufigste Fehler bei Accessibility ist das Fehlen von Beschreibungen für UI-Elemente. Das System TalkBack (Screenreader auf Android) kann Bilder oder Icons nicht lesen. Es braucht Text.

In Kotlin erledigst du das mit dem Attribut contentDescription. Aber nicht einfach „Button“, sondern sinnvoll.

Schlechtes Beispiel (mach das nicht)

imageView.contentDescription = "Button"

Gutes Beispiel

binding.fabAddTask.contentDescription = "Neue Aufgabe hinzufügen"

Wenn ein Icon dekorativ ist (nur zur Verschönerung) – setze contentDescription = null, damit TalkBack es ignoriert.

// Dekoratives Icon – Nutzer nicht ablenken\nbinding.decorativeIcon.contentDescription = null

Tipp: Nutze String-Ressourcen (strings.xml), um Lokalisierung zu unterstützen. Hardcode keinen deutschen Text in Kotlin-Dateien.

Semantische Auszeichnung: Dem System sagen, was wichtig ist

Standard-Views (Button, TextView) machen ihre Sache gut, aber benutzerdefinierte Komponenten brechen oft die Accessibility. In Kotlin können wir die Semantik explizit festlegen.

Einem Element eine Rolle geben

binding.customView.importantForAccessibility = View.IMPORTANT_FOR_ACCESSIBILITY_YES\nbinding.customView.accessibilityDelegate = object : View.AccessibilityDelegate() {\n    override fun onInitializeAccessibilityNodeInfo(host: View, info: AccessibilityNodeInfo) {\n        super.onInitializeAccessibilityNodeInfo(host, info)\n        info.text = "Aktueller Wert: ${viewModel.value}"\n        info.contentDescription = "Lautstärkeregler"\n    }\n}

Dieser Code sagt dem System: „Hey, das ist kein einfaches Quadrat, das ist ein Schieberegler!“. TalkBack versteht, dass das Element interaktiv ist, und kann korrekt damit interagieren.

Elemente gruppieren

Wenn du eine Produktkarte mit Bild, Preis und Name hast – fasse sie in einem Fokus zusammen. Sonst muss der Nutzer drei einzelne Elemente nacheinander anhören.

binding.cardProduct.apply {\n    isFocusable = true\n    contentDescription = "Produkt: ${product.name}, Preis: ${product.price} Euro"\n}

Jetzt liest TalkBack alle Informationen auf einmal vor.

Aktionsnavigation: Tastatur und D-Pad

Nicht alle Nutzer tippen auf den Bildschirm. Manche verwenden eine Tastatur (per OTG) oder einen D-Pad (Fernbedienung). Deine App muss auch ohne Berührung bedienbar sein.

In Kotlin löst du das mit focusable und der Fokus-Reihenfolge (nextFocusDown, nextFocusForward).

binding.buttonNext.nextFocusForwardId = R.id.buttonConfirm\nbinding.buttonConfirm.nextFocusDownId = R.id.buttonCancel

Prüfe, ob alle interaktiven Elemente den Fokus erhalten. Ein häufiger Fehler ist ein TextView mit ClickableSpan (Link im Text). Standardmäßig wird er nicht fokussiert. So behebst du das:

binding.textWithLink.movementMethod = LinkMovement