Accessibility Label — was es ist, Grundlagen und Verwendung für iOS und Android

Was ist Accessibility Label

Accessibility Label ist eine String-Eigenschaft, die den Namen eines Elements für unterstützende Technologien definiert. Wenn der Benutzer mit aktiviertem VoiceOver über den Bildschirm wischt, liest der Screenreader das Label des fokussierten Elements. Ohne Label hört der Benutzer nur den Elementtyp: „Button“, „Bild“ — ohne Angabe des Zwecks.

Laut Google I/O 2024, „Accessibility Testing“ stehen 35% der kritischen Barrierefreiheitsverstöße in Store-Apps im Zusammenhang mit fehlenden oder falschen Labels. Der Accessibility Scanner auf Android erkennt ein fehlendes Label als Fehler höchster Schwere.

Eine grundlegende Einschränkung: Das Label darf den Elementtyp nicht enthalten. VoiceOver und TalkBack fügen der Ansage automatisch die Rolle (Button, Überschrift, Link) hinzu. Wenn das Label „Senden-Button“ enthält, hört der Benutzer: „Senden-Button, Button“ — Dopplung.

Label und WCAG 4.1.2: Name, Rolle, Wert

WCAG 4.1.2 (Stufe A) verlangt, dass jedes Benutzeroberflächenelement einen programmatisch bestimmbaren Namen, eine Rolle und einen Wert hat. Accessibility Label liefert den Namen. Fehlt das Label, gilt das Kriterium als verletzt und die App besteht die grundlegende Zertifizierung nicht.

iOS: accessibilityLabel-Eigenschaft

In iOS wird accessibilityLabel von allen UIView vom UIAccessibility-Protokoll geerbt. Wenn ein Element Text enthält (UIButton mit Titel, UILabel mit Text), wird das Label automatisch auf diesen Text gesetzt. Für UIImageView, benutzerdefinierte Steuerelemente und Container muss das Label manuell gesetzt werden.

Beispiel für eine benutzerdefinierte Tabellenzelle:

class CustomTableViewCell: UITableViewCell {
    let titleLabel = UILabel()
    let priceLabel = UILabel()

    override func awakeFromNib() {
        super.awakeFromNib()
        self.isAccessibilityElement = true
        self.accessibilityLabel =
            "\(titleLabel.text ?? "") - \(priceLabel.text ?? "")"
    }
}

Für benutzerdefinierte UIView können Sie den accessibilityLabel-Getter überschreiben:

class RatingView: UIView {
    var rating: Int = 5

    override var accessibilityLabel: String? {
        get { return "Bewertung: \(rating) von 5" }
        set {}
    }
}

Apple HIG, 2024 empfiehlt: Besteht ein Element aus mehreren Unterelementen (z.B. eine Produktkarte mit Name und Preis), fassen Sie sie in einem einzigen Barrierefreiheitselement mit einem zusammengesetzten Label zusammen. Setzen Sie isAccessibilityElement = true auf dem Eltern- und false auf den Kindelementen.

NSAttributedString und accessibilityLabel

Wenn UILabel NSAttributedString verwendet, ist accessibilityLabel standardmäßig gleich .string (einfacher Text). Wenn Sie einen semantisch anderen Wert übergeben müssen (z.B. ein Symbol-Icon wird als „Stern“ statt des Zeichens ★ gelesen), setzen Sie accessibilityLabel explizit. VoiceOver liest Unicode-Zeichen nicht sinnvoll.

Android: Label via contentDescription

In Android fungiert contentDescription als Label für ImageView, ImageButton und benutzerdefinierte Views. Für TextView und Button mit integriertem Text ist das Setzen von contentDescription nicht erforderlich — TalkBack liest den Text automatisch.

Programmatisches Setzen via Kotlin:

binding.iconStar.contentDescription = "Produkt in Favoriten"

// Für benutzerdefinierte View mit mehreren Elementen
binding.customCard.setContentDescription(
    "\(title) für \(price)")

In XML für dekorative Elemente:

<ImageView
    android:contentDescription="@null"
    android:src="@drawable/divider"
    android:importantForAccessibility="no" />

Die Eigenschaft importantForAccessibility = „no“ schließt das Element vollständig aus dem Barrierefreiheitsbaum aus. In iOS ist das Äquivalent isAccessibilityElement = false.

Compose: semantics und contentDescription

In Jetpack Compose wird das Label über den semantics-Modifikator gesetzt:

Image(
    painter = painterResource(R.drawable.ic_search),
    contentDescription = "Produkte suchen",
    modifier = Modifier.semantics {
        contentDescription = "Produkte suchen"
    }
)

In Compose ist contentDescription ein erforderlicher Parameter für Image — ohne ihn wird der Code nicht kompiliert (Warnung). Dies verbessert zwangsweise die Barrierefreiheit durch API-Design.

Label und Hint: Rollenunterschied

Accessibility Label beantwortet die Frage „Was ist dieses Element?“. Hint (accessibilityHint in iOS, zusätzlicher Text in contentDescription in Android) — „Was passiert bei Interaktion?“. VoiceOver sagt sie nacheinander an: zuerst Label, dann Hint.

Beispiel für einen Löschen-Button:

• Label: „Löschen“
• Hint: „Löscht das ausgewählte Foto endgültig“
• VoiceOver: „Löschen. Löscht das ausgewählte Foto endgültig“

Laut Deque University, 2024 verbessert die richtige Trennung von Label und Hint die Aufgabenerfüllungsrate für VoiceOver-Benutzer um 28%. Benutzer mit kognitiven Beeinträchtigungen sind besonders auf Hint angewiesen: Wenn sie unsicher sind, „Löschen“ ohne Erklärung zu drücken, lehnen 40% die Aktion ab.

Wann Hint nicht nötig ist

• Element mit intuitiv verständlicher Aktion („Zurück“, „Schließen“ — Label reicht aus)
• Label beschreibt bereits das Ergebnis („Nachricht senden“ — Verb im Namen selbst)
• Systemsteuerelemente (UISwitch, UIButton mit Systemtyp) — ihr Verhalten ist standardmäßig

Häufige Fehler: Label statt Hint

Ein häufiger Fehler: Im Label „Löschen-Button“ statt „Löschen“ schreiben. Der Elementtyp (Button) wird von VoiceOver automatisch über ein Merkmal hinzugefügt. Der Benutzer hört dadurch: „Löschen-Button, Button“ — Dopplung. Richtiges Label: „Löschen“, Hint: „Löscht das ausgewählte Foto“.

Lokalisierung und Best Practices

Die Lokalisierung von Labels ist obligatorisch — sie erfolgt über Standardmechanismen: NSLocalizedString in iOS, String-Ressourcen @string/ in Android. Setzen Sie ein Label niemals durch Verkettung auf Englisch ohne Lokalisierung.

Regeln für gute Labels, basierend auf W3C WCAG 2.2:

• Beginnen Sie mit dem Schlüsselwort — „Produkte suchen“, nicht „Feld zum Suchen von Produkten“
• Fügen Sie keine Wörter wie „Button“, „Feld“, „Bild“ hinzu — die Rolle wird automatisch hinzugefügt
• Verwenden Sie natürliche Sprache, die für die Zielgruppe verständlich ist
• Vermeiden Sie Abkürzungen (außer allgemein üblichen: „St.“, „kg“) — der Screenreader liest sie wörtlich
• Fügen Sie bei Eingabeelementen ein Beispiel hinzu: „E-Mail (beispiel@domain.com)“

Konsistenz der Labels innerhalb der Marke

Verwenden Sie ein einheitliches Glossar für Labels in der gesamten App. Wenn auf einem Bildschirm „Favoriten“ und auf einem anderen „Lesezeichen“ steht, ist der Benutzer desorientiert. Erstellen Sie eine Barrierefreiheits-Terminologietabelle — stimmen Sie sich mit Designern und Lokalisierern ab.

Labels für Formularelemente

Für Eingabefelder (UITextField, EditText) sollte das Label mit dem Platzhalter oder der Feldbeschriftung übereinstimmen. Der Platzhalter verschwindet jedoch oft nach der Texteingabe. Verwenden Sie accessibilityLabel für den permanenten Namen und accessibilityValue für den aktuellen Feldinhalt — dies ist der WCAG 4.1.2-Standard. Lösung: Setzen Sie accessibilityLabel statisch (gleich der Feldbeschriftung) und accessibilityValue dynamisch (gleich dem eingegebenen Text). In iOS ist dies automatisch, aber für benutzerdefinierte Felder — manuell durch Überschreiben von accessibilityValue. Prüfen Sie, ob VoiceOver „E-Mail, beispiel@domain.com, Textfeld“ statt „, Textfeld“ liest.

So testen Sie Barrierefreiheits-Labels

Automatisierte Tests sind der einzige Weg, die Korrektheit der Labels auf allen Bildschirmen zu gewährleisten. iOS bietet XCUIApplication mit Zugriff auf .label, Android — AccessibilityCheckRule und setContentDescription.

Beispieltest für iOS:

func testLabelsAreUnique() {
    let app = XCUIApplication()
    app.launch()
    let allButtons = app.buttons.allElementsBoundByIndex
    let labels = allButtons.compactMap { $0.label }
    let uniqueLabels = Set(labels)
    XCTAssertEqual(labels.count, uniqueLabels.count,
        "Doppelte Labels gefunden")
}

Beispiel für Android mit Espresso:

@Test
fun testButtonHasAccessibilityLabel() {
    onView(withId(R.id.btnSubmit))
        .check(matches(
            withContentDescription(containsString("Senden"))
        ))
}

Manuelles Testen: Aktivieren Sie VoiceOver (iOS) oder TalkBack (Android) und wischen Sie nach rechts über alle Elemente auf dem Bildschirm. Jedes Element sollte eine sinnerfassende Ansage erhalten. Wenn Sie nur „Button“ oder „Bild“ hören — fehlt das Label.

VoiceOver-Rotor und Schnellnavigation

Nach dem Einrichten des Labels können VoiceOver-Benutzer den Rotor für die Schnellnavigation verwenden: Modi „Buttons“, „Überschriften“, „Links“ und andere. Wenn das Label richtig gesetzt ist, nimmt VoiceOver das Element in den entsprechenden Rotor-Modus auf. Prüfen Sie, ob alle Buttons im Modus „Buttons“ und alle Überschriften im Modus „Überschriften“ sichtbar sind.

Das Label beeinflusst auch die VoiceOver-Suche. Der Benutzer kann im Suchmodus ein Wort eingeben, und VoiceOver bewegt den Fokus zum Element mit dem passenden Label. Daher sollten Labels Schlüsselwörter enthalten, nach denen der Benutzer suchen wird.

CI/CD-Pipeline-Integration

Fügen Sie die Label-Prüfung zur Pipeline hinzu. Verwenden Sie unter iOS XCUITest mit fastlane scan. Verwenden Sie unter Android Accessibility Test Framework mit der AccessibilityCheckRule, die leere contentDescription erkennt. Dies verhindert Regressionen beim Zusammenführen neuer Bildschirme.