Barrierefreiheit — Grundlagen, VoiceOver und TalkBack für blinde Benutzer

Was ist Barrierefreiheit (a11y) in mobilen Apps?

Accessibility (abgekürzt a11y — 11 Buchstaben zwischen «a» und «y») — die Praxis, Anwendungen zu entwickeln, die von Menschen mit Seh-, Hör-, Motor- und kognitiven Beeinträchtigungen genutzt werden können. In der mobilen Entwicklung umfasst Barrierefreiheit vier Hauptszenarien: blinde Benutzer (Bildschirmlesegeräte), sehbehinderte Benutzer (Skalierung, Kontrast), gehörlose und schwerhörige Benutzer (Untertitel, visuelle Alternativen zu Ton) und Benutzer mit eingeschränkter Motorik (Sprachsteuerung, Switch Control, große Touchbereiche).

Rechtliche Anforderungen — in vielen Ländern ist Barrierefreiheit gesetzlich vorgeschrieben. USA: Section 508 und ADA. EU: European Accessibility Act (2025). Großbritannien: Equality Act 2010. Ohne Barrierefreiheit kann eine App zum Ziel von Klagen werden — in den USA wurden 2023 über 4.000 Klagen wegen unzugänglicher digitaler Produkte eingereicht. Apple und Google überprüfen die Barrierefreiheit bei der App-Moderation: App Store Review Guidelines (4.2) und Google Play Store verlangen eine minimale Barrierefreiheitsunterstützung.

Geschäftsargument — Barrierefreiheit erweitert Ihre Zielgruppe. Laut Return on Disability (2021) kontrollieren Menschen mit Behinderungen jährlich 13 Billionen US-Dollar verfügbares Einkommen. Zugängliche Apps werden auch in der Suche besser platziert (semantisches HTML, Alt-Texte), haben höhere Benutzerbewertungen und weniger Bewertungen zu UX-Problemen. Bei IT Sectr nehmen wir Barrierefreiheit in die Definition of Done aller Projekte auf — es ist ein Qualitätsstandard, keine optionale Verbesserung.

Barrierefreiheit in iOS: VoiceOver und UIAccessibility

VoiceOver — Apples Bildschirmlesegerät, integriert in iOS, iPadOS und macOS. Der Benutzer zieht seinen Finger über den Bildschirm, VoiceOver liest den Namen des Elements unter dem Finger vor. Doppeltippen aktiviert das Element. VoiceOver unterstützt über 40 Gesten: Drei-Finger-Wischen (Scrollen), Zwei-Finger-Doppeltippen (Stopp), Z-Geste (Zurück). Entwickler steuern, was und wie VoiceOver liest, über das UIAccessibility-Protokoll und die Eigenschaften accessibilityLabel, accessibilityTraits und accessibilityHint.

class CustomButton: UIButton {

    override var isAccessibilityElement: Bool {
        get { return true }
        set {}
    }

    // accessibilityLabel überschreiben
    override var accessibilityLabel: String? {
        get { return "Formular-Sendeschaltfläche" }
        set {}
    }

    // accessibilityHint überschreiben
    override var accessibilityHint: String? {
        get { return "Doppeltippen zum Senden von Daten" }
        set {}
    }

    // accessibilityTraits überschreiben
    override var accessibilityTraits: UIAccessibilityTraits {
        get { return .button }
        set {}
    }
}

// Dynamic Type — Textskalierung
titleLabel.font = UIFontMetrics.default.scaledFont(
    for: UIFont.systemFont(ofSize: 16)
)
titleLabel.adjustsFontForContentSizeCategory = true

Dynamische Typografie — Dynamic Type in iOS ermöglicht es dem Benutzer, die Textgröße (von XS bis XXXL) zu wählen. Entwickler verwenden UIFontMetrics.scaledFont für die automatische Skalierung. Der Text muss bei allen Größen korrekt angezeigt werden: Zeilen dürfen nicht abgeschnitten werden, Schaltflächen müssen proportional zum Text wachsen. UITableView aktualisiert automatisch die Zellenhöhen bei Änderung der Textgröße. Dynamic Type zu ignorieren bedeutet, Ihre App für sehbehinderte Benutzer unzugänglich zu machen.

Barrierefreiheit in SwiftUI

SwiftUI bietet Barrierefreiheitsmodifikatoren: .accessibilityLabel(), .accessibilityHint(), .accessibilityAddTraits(), .accessibilitySortPriority(). Standardmäßig sind alle standardmäßigen SwiftUI-Elemente (Text, Button, Image) bereits Barrierefreiheitselemente mit automatischen Bezeichnungen. Für benutzerdefinierte Ansichten verwenden Sie .accessibilityElement(children: .combine), um untergeordnete Elemente zu einem zu kombinieren. SwiftUI unterstützt automatisch Dynamic Type und VoiceOver.

VStack {
    Image(systemName: "trash")
        .accessibilityLabel(Text("Element löschen"))
    Text("Papierkorb")
        .font(.body)
}
.accessibilityElement(children: .combine)
.accessibilityAddTraits(.isButton)
.accessibilityHint(Text("Löscht das ausgewählte Element dauerhaft"))

Barrierefreiheit in Android: TalkBack und contentDescription

TalkBack — Googles Bildschirmlesegerät, vorinstalliert auf den meisten Android-Geräten (verfügbar im Google Play für alle Android 5+ Versionen). TalkBack verwendet dieselben Gesten wie VoiceOver: Wischen zur Navigation, Doppeltippen zum Aktivieren. Entwickler legen Elementbeschreibungen über das Attribut android:contentDescription in XML oder über setContentDescription() im Code fest. Für ImageView ist contentDescription obligatorisch — ohne es sagt TalkBack «nicht beschriftet» oder liest den Dateinamen.

// XML: contentDescription für ImageView
<ImageView
    android:id="@+id/iconDelete"
    android:src="@drawable/ic_delete"
    android:contentDescription="@string/delete_button_desc"
    android:focusable="true"
    android:clickable="true" />

// Kotlin: programmatische Zuweisung
iconDelete.contentDescription = getString(R.string.delete_button_desc)

// Accessibility Delegate (benutzerdefiniert)
iconDelete.accessibilityDelegate = object : View.AccessibilityDelegate() {
    override fun onInitializeAccessibilityNodeInfo(
        host: View, info: AccessibilityNodeInfo
    ) {
        super.onInitializeAccessibilityNodeInfo(host, info)
        info.text = "Löschen-Schaltfläche"
        info.contentDescription = "Ausgewähltes Element löschen"
        info.className = Button::class.java.name
    }
}

// Live Regions für dynamische Aktualisierungen
textView.accessibilityLiveRegion = View.ACCESSIBILITY_LIVE_REGION_POLITE

Live Regions — Androids Mechanismus zur Benachrichtigung von TalkBack über Inhaltsänderungen ohne Fokus. Das Attribut android:accessibilityLiveRegion akzeptiert drei Werte: none (keine Benachrichtigungen), polite (nach der aktuellen Ansage), assertive (sofortige Ansage). Verwenden Sie polite für Ladezustandsaktualisierungen, assertive für kritische Fehler. Übermäßiger Gebrauch von assertive verursacht Chaos für den Benutzer — TalkBack wird ständig die aktuelle Aktion unterbrechen.

Accessibility Scanner

Accessibility Scanner — eine kostenlose App von Google zum Testen der Barrierefreiheit von Android-Apps ohne Zugriff auf den Quellcode. Der Scanner prüft: Textkontrast, Touchbereichsgröße (mindestens 48×48dp gemäß Android-Barrierefreiheitsrichtlinien), contentDescription für ImageView und korrekte Elementhierarchie. Verwenden Sie für automatisierte Tests AccessibilityChecks von Espresso — sie integrieren sich in CI/CD und prüfen die Barrierefreiheit bei jedem Build.

WCAG 2.1: Kontrast, Größe und Touchbereiche

WCAG 2.1 (Web Content Accessibility Guidelines) — der von W3C entwickelte internationale Barrierefreiheitsstandard. Version 2.1 (2018) enthält 13 zusätzliche Kriterien für mobile Anwendungen. Konformitätsstufen: A (minimal), AA (für die meisten Organisationen obligatorisch), AAA (maximal). Apple und Google empfehlen Stufe AA als Minimum für die Veröffentlichung von Apps. WCAG 2.2 wurde 2023 mit Verfeinerungen für Fokus und Eingabe veröffentlicht.

Schlüsselkriterien für die mobile Entwicklung: Textkontrast von mindestens 4.5:1 (AA) oder 7:1 (AAA), Touchbereichsgröße von mindestens 44×44pt (iOS) oder 48×48dp (Android), Unterstützung von Quer- und Hochformat ohne Funktionsverlust, Möglichkeit zur Deaktivierung von Animationen (prefers-reduced-motion), Untertitel für Multimedia und Kompatibilität mit Sprachsteuerung (Voice Control auf iOS, Voice Access auf Android).

Kontrastprüfwerkzeuge — Colour Contrast Analyser (TPGI), WebAIM Contrast Checker, Stark (Figma), Accessibility Inspector (Xcode). Bei IT Sectr prüfen wir den Kontrast in der Designphase (Figma + Stark) und erneut in der Entwicklungsphase (Accessibility Inspector / Accessibility Scanner). Die Mindestanforderung ist 4.5:1 für gesamten Text unter 18pt (14pt fett). Logos und dekorative Elemente benötigen keinen Kontrast.

Barrierefreiheit testen: Werkzeuge und Checkliste

iOS-Tests — Accessibility Inspector in Xcode (Xcode → Open Developer Tool → Accessibility Inspector) prüft Bezeichnung, Traits und Hinweis für jedes Element. VoiceOver kann in den Einstellungen oder über die Barrierefreiheits-Verknüpfung (dreifacher Klick auf die Taste) aktiviert werden. Verwenden Sie für automatisierte Tests XCUITest mit XCTAssertTrue(app.staticTexts["label"].isAccessibilityElement). Apple empfiehlt, alle App-Bildschirme mit aktiviertem VoiceOver zu testen.

Android-Tests — Accessibility Scanner (Play Store) prüft Kontrast, Touchbereichsgröße und contentDescription. Für Automatisierung: Espresso AccessibilityChecks (Import: androidTestImplementation 'androidx.test.espresso:espresso-accessibility:3.5.1'). Google empfiehlt die folgende Checkliste: Jedes ImageView hat eine contentDescription, Touchbereiche sind mindestens 48×48dp, Text skaliert auf 200 % ohne Abschneiden und alle Elemente sind per TalkBack-Wischbewegung erreichbar.

IT Sectr-Checkliste — vor der Veröffentlichung überprüfen wir: (1) VoiceOver/TalkBack liest alle Elemente korrekt vor, (2) Text skaliert auf maximale Größe ohne Funktionsverlust, (3) alle ImageViews haben contentDescription, (4) Textkontrast ≥4.5:1 in allen Themes, (5) Touchbereiche ≥44pt/48dp, (6) kein Kontextmenü, das nur per langem Druck erreichbar ist, (7) Unterstützung für Reduce Motion / Remove Animations in den Systemeinstellungen. Diese Checkliste ist Teil der Definition of Done jedes Sprints.