Barrierefreie Apps entwickeln: Best Practices für Android und iOS (BITV & WCAG)

Barrierefreiheit wird bei der Entwicklung von Apps immer wichtiger. Spätestens seit dem European Accessibility Act, der ab 2025 für viele digitale Produkte gilt, steigt der Druck auf Unternehmen, ihre Anwendungen zugänglich zu gestalten. Für öffentliche Stellen in Deutschland ist Barrierefreiheit ohnehin verpflichtend – hier gilt die BITV 2.0 (Barrierefreie-Informationstechnik-Verordnung).

Doch auch unabhängig von gesetzlichen Anforderungen lohnt sich Accessibility: In Deutschland leben über 10 Millionen Menschen mit Behinderungen. Eine barrierefreie App erreicht also nicht nur mehr Nutzer, sondern verbessert oft auch die allgemeine Benutzerfreundlichkeit.

Als App Entwickler mit Fokus auf Android, Kotlin Multiplatform und iOS/SwiftUI achte ich deshalb in meiner täglichen Arbeit darauf, Accessibility möglichst früh in den Entwicklungsprozess zu integrieren.

In diesem Artikel teile ich typische Herausforderungen und Best Practices aus der Praxis.

Was bedeutet Barrierefreiheit bei Mobile Apps?

Die meisten Accessibility-Richtlinien basieren auf den WCAG (Web Content Accessibility Guidelines). Sie definieren vier grundlegende Prinzipien:

1. Wahrnehmbar (Perceivable)

Alle Informationen müssen für Nutzer wahrnehmbar sein – auch mit Assistenztechnologien wie Screenreadern.

Typische Anforderungen:

  • Unterstützung von Screenreadern (TalkBack / VoiceOver)
  • ausreichende Farbkontraste
  • skalierbare Schriftgrößen
  • Alternativtexte für Bilder

Beispiel: Image mit Content Description (Jetpack Compose)

Image(
    painter = painterResource(id = R.drawable.profile_picture),
    contentDescription = "Profilbild des Nutzers"
)

Ohne contentDescription kann ein Screenreader nicht erklären, was das Bild darstellt.

2. Bedienbar (Operable)

Alle Funktionen müssen für Nutzer bedienbar sein – auch ohne komplexe Gesten oder präzise Motorik.

Wichtige Aspekte:

  • ausreichend große Touch Targets
  • klare Fokusnavigation
  • keine zwingenden Mehrfinger-Gesten

Empfohlene Mindestgröße:

  • Android: 48dp
  • iOS: 44pt

Beispiel: Mindestgröße für Touch Targets

Button(
    onClick = { openSettings() },
    modifier = Modifier.sizeIn(minWidth = 48.dp, minHeight = 48.dp)
) {
    Text("Einstellungen")
}

3. Verständlich (Understandable)

Interfaces müssen verständlich sein – sowohl visuell als auch für Screenreader.

Typische Maßnahmen:

  • klare Labels
  • verständliche Fehlermeldungen
  • konsistente Navigation

Beispiel: Zugängliches Eingabefeld

TextField(
    value = email,
    onValueChange = { email = it },
    label = { Text("E-Mail-Adresse") }
)

Der Screenreader kann so den Zweck des Feldes korrekt ankündigen.

4. Robust (Robust)

Apps müssen mit unterschiedlichen Assistenztechnologien kompatibel sein.

Das bedeutet:

  • korrekt gesetzte Accessibility-Properties
  • semantische Struktur der UI
  • Unterstützung von Screenreadern und anderen Hilfsmitteln

Beispiel: Accessibility Semantics in Compose

Modifier.semantics {
    contentDescription = "Profilbild"
}

Typische Accessibility Probleme in Apps

In vielen bestehenden Apps sieht man immer wieder ähnliche Probleme.

Fehlende Content Descriptions

Ein häufiger Fehler ist das Fehlen von Beschreibungen für Icons oder Bilder.

Problematisches Beispiel

Icon(
    imageVector = Icons.Default.Settings,
    contentDescription = null
)

Ein Screenreader überspringt dieses Element oder kann seinen Zweck nicht erklären.

Besser

Icon(
    imageVector = Icons.Default.Settings,
    contentDescription = "Einstellungen öffnen"
)

Zu kleine Touch Targets

Gerade bei minimalistischen Designs werden Buttons oder Icons oft zu klein.

Problematisch:

  • schwer zu bedienen für Menschen mit motorischen Einschränkungen
  • erhöhte Fehlbedienungen

Empfehlung:

  • mindestens 48dp (Android) oder 44pt (iOS)

Falsche Fokus-Reihenfolge

Besonders bei komplexen Layouts kann die Fokusreihenfolge für Screenreader unlogisch werden.

Typisches Beispiel:

  • UI wird mit mehreren Containern aufgebaut
  • visuelle Reihenfolge ≠ Accessibility-Reihenfolge

Das führt dazu, dass Screenreader Inhalte in einer verwirrenden Reihenfolge vorlesen.

Nur Farbe als Information

Ein Klassiker im UI-Design:

  • Grün = Erfolg
  • Rot = Fehler

Für Menschen mit Farbsehschwäche funktioniert das nicht.

Beispiel

Text(
    text = "Fehler: Passwort zu kurz",
    color = Color.Red
)

Besser ist zusätzlich eine klare textliche Beschreibung.

Best Practices für barrierefreie Apps

Aus meiner Erfahrung gibt es einige einfache Regeln, die einen großen Unterschied machen.

Accessibility von Anfang an mitdenken

Accessibility nachträglich einzubauen ist oft aufwendig.

Besser:

  • schon im Designprozess
  • im Design System
  • bei Code Reviews

Fragen, die ich mir dabei stelle:

  • Kann ein Screenreader dieses Element verstehen?
  • Ist der Touch Target groß genug?
  • Funktioniert die UI bei großer Schrift?

Screenreader regelmäßig testen

Der einfachste Accessibility-Test ist oft der effektivste.

Android:

  • TalkBack aktivieren
  • durch die App navigieren

iOS:

  • VoiceOver testen

Dabei fallen viele Probleme sofort auf:

  • fehlende Labels
  • falsche Fokusreihenfolge
  • unverständliche Ansagen

Semantische Komponenten nutzen

Moderne UI-Frameworks unterstützen Accessibility bereits sehr gut.

Jetpack Compose

Row(
    modifier = Modifier.semantics {
        contentDescription = "Profil des Nutzers öffnen"
    }
)

SwiftUI

Image("profile")
    .accessibilityLabel("Profilbild")

Damit können Screenreader den Zweck eines Elements korrekt erklären.

Dynamische Schriftgrößen unterstützen

Viele Nutzer erhöhen die Schriftgröße systemweit.

Apps sollten darauf reagieren.

Android:

  • sp statt dp für Schriftgrößen

iOS:

  • Dynamic Type

Compose Beispiel

Text(
    text = "Willkommen",
    fontSize = 18.sp
)

Herausforderungen bei BITV-konformen Apps

In der Praxis gibt es einige typische Herausforderungen.

Legacy Apps

Ältere Apps wurden oft ohne Accessibility entwickelt.

Typische Probleme:

  • fehlende Content Descriptions
  • starre Layouts
  • keine Skalierung für große Schrift

Hier braucht es oft Refactoring statt kleiner Fixes.

Komplexe Custom Components

Standard-UI-Komponenten sind meist gut zugänglich.

Schwieriger wird es bei:

  • Charts
  • Canvas Zeichnungen
  • Karten
  • interaktiven Visualisierungen

Hier muss oft ein eigener Accessibility Tree aufgebaut werden.

Design vs Accessibility

Manchmal kollidieren Designwünsche mit Accessibility-Anforderungen.

Beispiele:

  • zu geringer Farbkontrast
  • Icon-only Navigation
  • sehr kleine UI-Elemente

Hier hilft eine enge Zusammenarbeit zwischen:

  • Design
  • Produkt
  • Entwicklung

Meine persönliche Accessibility-Checkliste

Bei der Entwicklung neuer Features gehe ich meist eine einfache Checkliste durch:

  • sinnvolle Content Descriptions für Icons und Bilder
  • Touch Targets ≥ 48dp
  • ausreichender Farbkontrast
  • TalkBack / VoiceOver Test durchführen
  • Unterstützung von Dynamic Font Scaling
  • sinnvolle Focus Navigation

Diese Punkte lassen sich meist mit relativ wenig Aufwand umsetzen, verbessern aber die Nutzbarkeit einer App erheblich.

Fazit

Barrierefreiheit ist kein optionales Feature, sondern ein wichtiger Bestandteil moderner App-Entwicklung.

Viele Accessibility-Probleme lassen sich vermeiden, wenn man sie früh im Entwicklungsprozess berücksichtigt. Gleichzeitig verbessert eine zugängliche App häufig auch die allgemeine User Experience für alle Nutzer.

Als Entwickler lohnt es sich daher, Accessibility nicht nur als Pflicht zu sehen, sondern als Teil von guter Softwarequalität.

Wenn Sie Unterstützung bei der Entwicklung barrierefreier Android oder iOS Apps benötigen oder bestehende Anwendungen hinsichtlich BITV und Accessibility verbessern möchten, können Sie mich gerne kontaktieren.