App Barrierefreiheit 2025: BFSG-Pflicht & 5 Quick Wins für Accessibility

Barrierefreiheit in Apps war lange ein "Nice-to-have" – etwas, das engagierte Entwickler freiwillig umgesetzt haben. Ab dem 28. Juni 2025 ändert sich das grundlegend. Mit dem Barrierefreiheitsstärkungsgesetz (BFSG) wird Accessibility für viele digitale Produkte zur gesetzlichen Pflicht.

In diesem Artikel erkläre ich, was das BFSG für App-Betreiber bedeutet, wer betroffen ist – und gebe Ihnen 5 konkrete Quick Wins, mit denen Sie Ihre App sofort barrierefreier machen können.

Das BFSG: Was ist das eigentlich?

Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt die EU-Richtlinie 2019/882 (European Accessibility Act) in deutsches Recht um. Es tritt am 28. Juni 2025 in Kraft.

Das Ziel: Menschen mit Behinderungen sollen digitale Produkte und Dienstleistungen gleichberechtigt nutzen können.

Welche Apps sind betroffen?

Das BFSG betrifft nicht alle Apps, aber einen großen Teil:

• E-Commerce-Apps – Online-Shops, Marktplätze
• Banking- und Finanz-Apps – Zahlungsdienste, Online-Banking
• Telekommunikations-Apps – Messenger mit Telefonie-Funktion
• E-Books und E-Reader
• Transport-Apps – Ticketing, Fahrplanauskunft (Flug, Bahn, ÖPNV)
• Behörden-Apps – waren schon vorher verpflichtet (BITV 2.0)

Was droht bei Verstößen?

Das BFSG hat Zähne:

• Bußgelder bis zu 100.000 € bei Verstößen
• Marktüberwachungsbehörden können Produkte vom Markt nehmen
• Verbraucher können Beschwerde einreichen
• Verbände können Unterlassungsklagen führen

Dazu kommt: Reputationsschaden. Eine App, die öffentlich als nicht barrierefrei kritisiert wird, verliert Vertrauen – bei allen Nutzern, nicht nur bei Betroffenen.

WCAG 2.1: Der technische Standard

Das BFSG verweist auf die EN 301 549, die wiederum auf den WCAG 2.1 Standard (Web Content Accessibility Guidelines) aufbaut. WCAG definiert drei Konformitätsstufen:

• Stufe A: Grundlegende Barrierefreiheit
• Stufe AA: Vom BFSG gefordert – der Mindeststandard
• Stufe AAA: Höchste Stufe – nice-to-have, aber nicht gefordert

Die vier Prinzipien von WCAG:

1. Wahrnehmbar – Inhalte müssen für alle Sinne zugänglich sein
2. Bedienbar – Navigation muss ohne Maus/Touch funktionieren
3. Verständlich – Inhalte und Bedienung müssen klar sein
4. Robust – Inhalte müssen mit Hilfstechnologien funktionieren

Warum sich Barrierefreiheit lohnt – auch ohne Pflicht

Selbst wenn Ihre App nicht unter das BFSG fällt: Barrierefreiheit ist ein Business Case, nicht nur ein Compliance-Thema.

Die Zahlen sprechen für sich

• ~10-15% der Bevölkerung haben eine anerkannte Behinderung
• ~20-25% haben situative oder temporäre Einschränkungen (gebrochener Arm, grelles Sonnenlicht, laute Umgebung)
• 100% profitieren von besserem Design (größere Buttons, bessere Kontraste, klare Struktur)

Die Business-Vorteile

• Größere Zielgruppe: Sie schließen niemanden aus
• Bessere UX für alle: Accessibility-Optimierungen verbessern die gesamte App
• SEO-Vorteile: Saubere Struktur, Alt-Texte, semantisches HTML
• Rechtssicherheit: Sie sind vorbereitet, wenn sich Gesetze ändern
• Positive PR: Inklusion ist ein starkes Markensignal

Quick Win #1: Farbkontraste prüfen und verbessern

Das Problem: Zu geringe Kontraste zwischen Text und Hintergrund machen Inhalte für Menschen mit Sehschwäche unlesbar – aber auch für jeden bei Sonnenlicht auf dem Smartphone.

Der Standard: WCAG AA fordert:

• Normaler Text: Kontrastverhältnis mindestens 4.5:1
• Großer Text (ab 18pt oder 14pt fett): Mindestens 3:1
• UI-Komponenten und Grafiken: Mindestens 3:1

Sofort umsetzen:

1. Prüfen Sie Ihre Farben mit dem WebAIM Contrast Checker
2. Vermeiden Sie Grau-auf-Grau und Pastell-auf-Weiß
3. Testen Sie bei direktem Sonnenlicht auf echten Geräten

Quick Win #2: Touch-Targets vergrößern

Das Problem: Zu kleine Buttons und Links sind schwer zu treffen – für Menschen mit motorischen Einschränkungen unmöglich, für alle anderen frustrierend.

Der Standard:

• Apple Human Interface Guidelines: Mindestens 44x44 Punkte
• Google Material Design: Mindestens 48x48 dp
• WCAG 2.2 (neu): Mindestens 24x24 CSS-Pixel, empfohlen 44x44

Sofort umsetzen:

1. Messen Sie Ihre Buttons – alles unter 44pt ist zu klein
2. Erhöhen Sie den tappable Bereich, auch wenn das Icon klein bleibt (Padding!)
3. Abstand zwischen Targets: Mindestens 8pt, besser mehr

// iOS: Touch-Target vergrößern ohne visuelles Element zu ändern
button.contentEdgeInsets = UIEdgeInsets(top: 12, left: 12, bottom: 12, right: 12)

// Oder: Minimale Größe erzwingen
button.heightAnchor.constraint(greaterThanOrEqualToConstant: 44).isActive = true
button.widthAnchor.constraint(greaterThanOrEqualToConstant: 44).isActive = true

// Android: Minimum Touch Target in XML
android:minHeight="48dp"
android:minWidth="48dp"

// Oder: TouchDelegate für größeren Bereich
val parent = button.parent as View
parent.post {
    val rect = Rect()
    button.getHitRect(rect)
    rect.inset(-24, -24) // 24dp extra auf jeder Seite
    parent.touchDelegate = TouchDelegate(rect, button)
}

Quick Win #3: Screen Reader-Kompatibilität sicherstellen

Das Problem: VoiceOver (iOS) und TalkBack (Android) können nur lesen, was korrekt ausgezeichnet ist. Ohne Labels sind Buttons nur "Taste", Bilder nur "Bild".

Sofort umsetzen:

Accessibility Labels vergeben

// iOS: Accessibility Label
submitButton.accessibilityLabel = "Bestellung absenden"
submitButton.accessibilityHint = "Sendet Ihre Bestellung ab und leitet zur Bestätigung weiter"

// Für Bilder
productImage.accessibilityLabel = "Rotes T-Shirt, Größe M, 29,99 Euro"
productImage.isAccessibilityElement = true

// Dekorative Bilder ausblenden
decorativeImage.isAccessibilityElement = false

// Android: Content Description
submitButton.contentDescription = "Bestellung absenden"

// Für komplexe Elemente
ViewCompat.setAccessibilityDelegate(customView, object : AccessibilityDelegateCompat() {
    override fun onInitializeAccessibilityNodeInfo(host: View, info: AccessibilityNodeInfoCompat) {
        super.onInitializeAccessibilityNodeInfo(host, info)
        info.text = "Produktdetails: Rotes T-Shirt, 29,99 Euro"
        info.addAction(AccessibilityNodeInfoCompat.ACTION_CLICK)
    }
})

Testen Sie selbst mit Screen Reader

1. iOS: Einstellungen → Bedienungshilfen → VoiceOver aktivieren
2. Android: Einstellungen → Bedienungshilfen → TalkBack aktivieren
3. Navigieren Sie blind durch Ihre App – was fehlt? Was ist verwirrend?

Quick Win #4: Dynamische Schriftgrößen unterstützen

Das Problem: Viele Menschen stellen größere Systemschriften ein – aber Apps ignorieren das und zeigen alles in fester Größe.

Der Standard: Text sollte auf 200% skalierbar sein, ohne Funktionsverlust.

Sofort umsetzen:

// iOS: Dynamic Type unterstützen
label.font = UIFont.preferredFont(forTextStyle: .body)
label.adjustsFontForContentSizeCategory = true

// In SwiftUI
Text("Produktbeschreibung")
    .font(.body) // Skaliert automatisch

// Android: Skalierbare sp-Einheit verwenden (nicht dp für Text!)
android:textSize="16sp"

// In Compose
Text(
    text = "Produktbeschreibung",
    style = MaterialTheme.typography.bodyLarge // Skaliert automatisch
)

Wichtig: Testen Sie mit maximaler Schriftgröße!

• iOS: Einstellungen → Anzeige → Textgröße → Maximum + "Größerer Text"
• Android: Einstellungen → Anzeige → Schriftgröße → Maximum

Prüfen Sie: Wird Text abgeschnitten? Überlappen Elemente? Funktioniert die Navigation noch?

Quick Win #5: Informationen nicht nur durch Farbe vermitteln

Das Problem: "Rot = Fehler, Grün = OK" funktioniert nicht für farbenblinde Menschen (~8% der Männer!).

Der Standard: Farbe darf nie das einzige Mittel sein, um Informationen zu vermitteln.

Sofort umsetzen:

• Icons zusätzlich zur Farbe: ✓ für Erfolg, ✗ für Fehler
• Text zusätzlich zur Farbe: "Fehler: Bitte E-Mail eingeben" statt nur roter Rahmen
• Muster zusätzlich zur Farbe: In Diagrammen unterschiedliche Linienarten/Schraffuren

Ihre Accessibility-Audit-Checkliste

Hier eine Kurzversion zum Abhaken:

Kriterium	Check	Priorität
Alle Texte haben Kontrast ≥ 4.5:1	☐	Hoch
Touch-Targets mindestens 44x44pt	☐	Hoch
Alle interaktiven Elemente haben Labels	☐	Hoch
App funktioniert mit VoiceOver/TalkBack	☐	Hoch
Dynamische Schriftgrößen werden unterstützt	☐	Mittel
Keine Information nur durch Farbe	☐	Mittel
Fokus-Reihenfolge ist logisch	☐	Mittel
Animationen können deaktiviert werden	☐	Mittel
Timeout-Warnungen mit Verlängerungsoption	☐	Niedrig
Untertitel für Videos	☐	Je nach Content

Tools für Accessibility-Tests

Automatisierte Tests:

• Xcode Accessibility Inspector (iOS) – kostenlos, in Xcode integriert
• Android Accessibility Scanner (Android) – kostenlose App von Google
• Axe DevTools – für Web-Inhalte in Hybrid-Apps

Manuelle Tests (unverzichtbar!):

• VoiceOver (iOS) – selbst durchnavigieren
• TalkBack (Android) – selbst durchnavigieren
• Switch Control (iOS) – für motorische Einschränkungen
• Farbfilter/Graustufen – in den Bedienungshilfen aktivieren

Tipp: Automatisierte Tools finden ~30% der Probleme. Die restlichen 70% finden Sie nur durch manuelles Testen mit echten Hilfstechnologien.

Fazit: Jetzt anfangen, nicht erst im Juni 2025

Das BFSG kommt – und es ist gut so. Barrierefreiheit macht Apps besser für alle, nicht nur für Menschen mit Behinderungen.

Meine Empfehlung:

1. Heute: VoiceOver/TalkBack aktivieren und Ihre App selbst testen
2. Diese Woche: Die 5 Quick Wins umsetzen (Kontraste, Touch-Targets, Labels)
3. Diesen Monat: Accessibility-Audit durchführen und priorisieren
4. Vor Juni 2025: WCAG 2.1 AA-Konformität erreichen

Barrierefreiheit ist kein Projekt mit Enddatum – es ist eine Haltung. Jede neue Funktion, jedes Update sollte von Anfang an barrierefrei gedacht werden. Das spart Zeit, Geld und macht Ihre App für 100% der Nutzer besser.