Content Description: Was es ist, Prinzipien und wie man es für Barrierefreiheit festlegt

Was ist Content Description in der Barrierefreiheit

Content Description ist eine String-Eigenschaft eines UI-Elements, die eine textuelle Repräsentation von visuellem Inhalt für assistierende Technologien bereitstellt. Ein Screenreader (VoiceOver auf iOS, TalkBack auf Android) liest die Beschreibung vor, anstatt zu versuchen, das Element visuell zu erkennen. Beschreibungen werden auf Bilder ohne Textebene, Symbole, Diagramme, benutzerdefinierte Steuerelemente und alle nicht-textuellen Elemente angewendet.

Laut Google Material Design, 2024 verstoßen Elemente ohne contentDescription gegen WCAG 1.1.1 (Non-text Content). Accessibility Scanner-Prüfungen zeigen, dass bis zu 40 % der Symbole in Shopping-Apps keine Beschreibungen haben. Ein VoiceOver-Benutzer hört „Bild“ oder „Schaltfläche“ ohne Näheres — eine solche Oberfläche wird für die Navigation unbrauchbar.

Content Description ersetzt nicht den sichtbaren Text eines Elements. Wenn eine Schaltfläche die Textbeschriftung „Senden“ enthält, muss keine zusätzliche Beschreibung festgelegt werden — der Screenreader liest den Text vor. Für Bilder, Symbole und Eingabefelder ist eine Beschreibung obligatorisch.

Die Tools Accessibility Scanner (Android) und Xcode Accessibility Inspector (iOS) prüfen automatisch auf das Vorhandensein von Beschreibungen. Es wird empfohlen, diese Prüfungen auf jedem Bildschirm vor der Veröffentlichung durchzuführen.

Warum Content Description wichtig ist: Benutzerszenarien

Ein Benutzer mit Sehbehinderung verlässt sich auf VoiceOver, um die Oberfläche zu verstehen. Wenn ein Warenkorbsymbol keine Beschreibung hat, hört er nur „Schaltfläche“. Um herauszufinden, was die Schaltfläche tut, muss er sie blind drücken — mit dem Risiko einer irreversiblen Aktion. Eine Beschreibung wie „Artikel aus dem Warenkorb entfernen“ löst dieses Problem in einer Sekunde.

Ein Benutzer mit vorübergehenden Einschränkungen (grelle Sonne draußen, kaputter Bildschirm) verwendet ebenfalls VoiceOver. Laut Apple Accessibility Report, 2023 haben etwa 20 % der VoiceOver-Benutzer keine dauerhaften Sehbehinderungen — sie schalten die Funktion situativ ein.

WCAG 1.1.1: Nicht-textuelle Inhalte

Das Kriterium WCAG 1.1.1 (Stufe A) verlangt, dass alle nicht-textuellen Inhalte eine Textalternative haben. Ausnahme: Inhalte, die dekorativ sind, nur zur visuellen Darstellung verwendet werden oder keine Informationen vermitteln. Der Dekorativitätstest: Wenn Sie das Element entfernen, ändert sich die Bedeutung der Seite? Wenn nicht — kann es vor dem Screenreader versteckt werden.

Wie unterscheidet sich Content Description von Label

Accessibility Label (accessibilityLabel in iOS) ist der Name des Elements, den der Screenreader bei Fokus ausspricht. Content Description (accessibilityHint in iOS) ist eine zusätzliche Erläuterung, die nach dem Namen angesagt wird und das Ergebnis einer Aktion mitteilt.

Der Unterschied wird am Beispiel einer „Warenkorb“-Schaltfläche deutlich. Label: „Warenkorb“. Description: „Öffnet den Bezahlbildschirm“. VoiceOver sagt: „Warenkorb. Öffnet den Bezahlbildschirm“. Wenn nur das Label festgelegt ist, erfährt der Benutzer nicht, was nach dem Drücken passiert.

Tabelle: Label versus Description

Regel: Label beantwortet „Was ist das?“, Description beantwortet „Was wird passieren?“ In Android kann contentDescription beide Rollen erfüllen, aber in der Praxis ist es besser, sie zu trennen: Verwenden Sie die Verkettung „[Name], [Erklärung]“.

Wann Description wichtiger ist als Label

Für komplexe Gesten (Wischen zum Löschen, langes Drücken für Kontextmenü) ist accessibilityHint obligatorisch. Ein VoiceOver-Benutzer kennt versteckte Gesten nicht, wenn sie nicht beschrieben sind. Geben Sie an: „Zum Löschen nach links wischen“ im Hint des Elements.

iOS: Das Attribut accessibilityHint

Auf der iOS-Plattform wird accessibilityHint über die gleichnamige Eigenschaft von UIView oder NSObject festgelegt. Der Wert ist ein String mit bis zu 80 Zeichen. VoiceOver liest den Hint nach dem Label vor, wenn der Modus für detaillierte Beschreibungen aktiviert ist (in den VoiceOver-Einstellungen — „Verbosity“).

Beispiel zum Festlegen eines Hints für eine benutzerdefinierte Schaltfläche:

import UIKit

class CustomButton: UIButton {
    override func awakeFromNib() {
        super.awakeFromNib()
        self.accessibilityLabel = "Zu Favoriten hinzufügen"
        self.accessibilityHint = "Speichert den Artikel in der Favoritenliste"
    }
}

Für UIImageView ohne Textinhalt müssen isAccessibilityElement = true und accessibilityHint festgelegt werden:

let imageView = UIImageView(image: UIImage(named: "chart-sales"))
imageView.isAccessibilityElement = true
imageView.accessibilityHint = "Verkaufsdiagramm für das letzte Quartal"

VoiceOver liest: „Verkaufsdiagramm für das letzte Quartal“. Wenn der Hint leer ist — nur „Bild“. Apple HIG, 2024 empfiehlt, in Hints keine Verben wie „tippen“ oder „drücken“ zu verwenden — VoiceOver fügt automatisch eine Gestenanweisung hinzu.

SwiftUI: Der accessibilityHint-Modifikator

In SwiftUI wird der Hint über einen Chain-Modifikator festgelegt:

Image(systemName: "trash")
    .accessibilityLabel("Löschen")
    .accessibilityHint("Löscht das ausgewählte Element dauerhaft")

SwiftUI kombiniert automatisch die Modifikatoren für zusammengesetzte Ansichten. Wenn sich ein Image innerhalb eines Button befindet, verwendet SwiftUI die Beschriftung des Buttons als primären accessibilityLabel.

Android: Die Eigenschaft contentDescription

In Android wird contentDescription entweder im XML-Markup oder programmatisch über setContentDescription() festgelegt. TalkBack sagt die Beschreibung an, wenn das Element den Fokus erhält.

Beispiel in XML:

<ImageView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:src="@drawable/ic_search"
    android:contentDescription="Produkte suchen" />

Programmatische Einstellung für dynamische Elemente:

binding.iconSearch.contentDescription =
    "Suche. Öffnet den Suchbildschirm mit Filtern"

Für dekorative Bilder (Trennlinien, Hintergründe, dekorative Symbole) setzen Sie contentDescription = "@null" oder setContentDescription(null) — TalkBack überspringt solche Elemente. In XML: android:contentDescription="@null". Ein leerer String "" funktioniert nicht — TalkBack sagt trotzdem „Bild“ an.

Android: Wichtige Details für ImageButton und CheckBox

Für ImageButton setzen Sie immer contentDescription — TalkBack sieht keinen Text auf Bildern. Für CheckBox sollte sich die Beschreibung dynamisch ändern: „Ausgewählt“ / „Nicht ausgewählt“ statt einer statischen Beschreibung. Verwenden Sie setContentDescription im Zustands-Listener.

Regeln zum Schreiben von Beschreibungen

Informativität — die Beschreibung sollte Bedeutung vermitteln, nicht das Aussehen. Nicht „Blaues Symbol mit Häkchen“, sondern „Artikel zum Warenkorb hinzugefügt“. Ein Screenreader interessiert sich nicht für Farben — er interessiert sich für das Ergebnis.

Kürze — die optimale Länge beträgt 2–4 Wörter (bis zu 80 Zeichen). Lange Beschreibungen verlangsamen die Navigation: VoiceOver liest sequenziell, jedes Wort ist eine Sekunde der Benutzerzeit. Laut Apple WWDC 2023, „Accessibility by Design“ unterbricht ein Satz, der länger als 5 Sekunden zum Lesen braucht, den kognitiven Fluss.

Eindeutigkeit — es sollten nicht zwei Elemente auf demselben Bildschirm mit derselben Beschreibung geben. Der Benutzer kann nicht unterscheiden, welches Ergebnis der Fokus auf das erste gegenüber dem zweiten Element auslöst. Wenn es mehrere „Kaufen“-Schaltflächen gibt, fügen Sie einen Identifikator hinzu: „iPhone 15 kaufen“, „iPhone 15 Pro kaufen“.

Lokalisierung — Content Description muss in alle Sprachen übersetzt werden, die die App unterstützt. Ein Lokalisierungsfehler in den Beschreibungen ist einer der häufigen Gründe für das Scheitern einer Accessibility Review im App Store.

Länge der Beschreibung: Forschung

Eine Studie der Nielsen Norman Group, 2024 zeigte, dass die optimale Beschreibungslänge für Screenreader 3–5 Wörter (bis zu 50 Zeichen) beträgt. Längere Beschreibungen reduzieren die Navigationsgeschwindigkeit um 30 %, da der Benutzer warten muss, bis die Ansage vor dem nächsten Schritt beendet ist.

Häufige Fehler bei der Verwendung

Redundanz — die Beschreibung dupliziert den sichtbaren Text. Wenn eine Schaltfläche den Text „Senden“ enthält, setzen Sie nicht accessibilityHint = „Senden-Schaltfläche“. VoiceOver liest den Text automatisch vor, und der Hint fügt unnötiges Rauschen hinzu.

Verwechslung mit Label — Verwendung von contentDescription anstelle eines Labels für Textschaltflächen. In iOS sollte accessibilityLabel mit dem Schaltflächentext übereinstimmen (oder leer sein, wenn der Text bereits sichtbar ist), und der Hint sollte nur die Aktion erklären. Laut Google Testing Blog, 2024 haben 23 % der überprüften Apps im Play Store doppelte Beschreibungen.

Ignorieren von Dynamik — die Beschreibung wird bei Zustandsänderung nicht aktualisiert. Zum Beispiel bleibt die Beschreibung eines „Wi-Fi“-Schalters „Wi-Fi aktivieren“, auch nachdem er eingeschaltet wurde. Richtiger Ansatz: Die Beschreibung dynamisch auf „Wi-Fi deaktivieren“ ändern, indem der Zustand beobachtet wird.

Renderzyklen und Regressionen

Nach einem Design-Update (Symboländerungen, Neuanordnung von Elementen) geht Content Description oft verloren. Grund: Der Designer ersetzt ein Bild, und der Entwickler prüft die Barrierefreiheitseigenschaften des neuen Assets nicht. Lösung: Machen Sie die Barrierefreiheitsprüfung zu einem obligatorischen Schritt im Code-Review — fügen Sie einen Checklistenpunkt hinzu: „Wurde Content Description aktualisiert?“

Wie man Content Description überprüft

• In iOS: Xcode → Accessibility Inspector — Element auswählen, Label- und Hint-Felder prüfen
• In Android: Accessibility Scanner aus dem Play Store installieren — auf Ihrem Bildschirm ausführen
• Auf beiden Plattformen: VoiceOver/TalkBack aktivieren und den gesamten Bildschirm mit Gesten navigieren
• Schreiben Sie einen UI-Test, der contentDescription für alle ImageView-Elemente prüft

Beispiel UI-Test für iOS

func testContentDescriptionExists() {
    let app = XCUIApplication()
    app.launch()
    let image = app.images["chart-sales"]
    XCTAssertNotNil(image.label)
    XCTAssertGreaterThan(image.label.count, 0)
}