Barrierefreiheit (WCAG 2.2)

Was macht Barrierefreiheit (WCAG 2.2)?

Diese Kompetenz stellt sicher, dass digitale Oberflächen für alle Benutzer wahrnehmbar, bedienbar, verständlich und robust (POUR) sind – einschließlich Personen, die Screenreader, Schaltersteuerungen oder Tastaturnavigation verwenden. Sie konzentriert sich auf die technische Umsetzung der WCAG 2.2-Erfolgskriterien.

Verwendungszweck

• Definieren von UI-Komponentenspezifikationen für Web, iOS oder Android.
• Prüfen vorhandenen Codes auf Barrierefreiheitshindernisse oder Compliance-Lücken.
• Implementieren neuer WCAG 2.2-Standards wie Zielgröße (Minimum) und Fokusdarstellung.
• Abbilden von Designanforderungen auf technische Attribute (ARIA-Rollen, Traits, Hinweise).

Kernkonzepte

• POUR-Prinzipien: Die Grundlage von WCAG (Wahrnehmbar, Bedienbar, Verständlich, Robust).
• Semantische Abbildung: Verwendung nativer Elemente anstelle generischer Container für integrierte Barrierefreiheit.
• Barrierefreiheitsbaum: Die Darstellung der Benutzeroberfläche, die assistive Technologien tatsächlich „lesen".
• Fokusverwaltung: Steuerung der Reihenfolge und Sichtbarkeit des Tastatur-/Screenreader-Cursors.
• Beschriftungen & Hinweise: Bereitstellung von Kontext durch aria-label, accessibilityLabel und contentDescription.

Funktionsweise

Schritt 1: Identifizieren Sie die Komponentenrolle

Bestimmen Sie den funktionalen Zweck (z. B. Handelt es sich um eine Schaltfläche, einen Link oder einen Tab?). Verwenden Sie das semantischste native Element, bevor Sie auf benutzerdefinierte Rollen zurückgreifen.

Schritt 2: Definieren Sie wahrnehmbare Attribute

• Stellen Sie einen Textkontrast von 4,5:1 (normal) oder 3:1 (groß/UI) sicher.
• Fügen Sie Textalternativen für nicht-textliche Inhalte (Bilder, Symbole) hinzu.
• Implementieren Sie responsiven Fluss (bis zu 400 % Zoom ohne Funktionsverlust).

Schritt 3: Implementieren Sie bedienbare Steuerelemente

• Stellen Sie eine Mindestzielgröße von 24x24 CSS-Pixel sicher (WCAG 2.2 SC 2.5.8).
• Überprüfen Sie, ob alle interaktiven Elemente über die Tastatur erreichbar sind und eine sichtbare Fokusanzeige haben (SC 2.4.11).
• Bieten Sie Einzelzeigeralternativen für Ziehbewegungen.

Schritt 4: Stellen Sie verständliche Logik sicher

• Verwenden Sie konsistente Navigationsmuster.
• Geben Sie beschreibende Fehlermeldungen und Korrekturvorschläge (SC 3.3.3).
• Implementieren Sie „Redundante Eingabe" (SC 3.3.7), um zu vermeiden, dass dieselben Daten zweimal abgefragt werden.

Schritt 5: Überprüfen Sie die robuste Kompatibilität

• Verwenden Sie korrekte Name, Rolle, Wert-Muster.
• Implementieren Sie aria-live oder Live-Regionen für dynamische Statusaktualisierungen.

Architekturdiagramm der Barrierefreiheit

flowchart TD
  UI["UI-Komponente"] --> Platform{Plattform?}
  Platform -->|Web| ARIA["WAI-ARIA + HTML5"]
  Platform -->|iOS| SwiftUI["Barrierefreiheit-Traits + Labels"]
  Platform -->|Android| Compose["Semantik + InhaltBeschreibung"]

  ARIA --> AT["Assistive Technologie (Screenreader, Schalter)"]
  SwiftUI --> AT
  Compose --> AT

Plattformübergreifende Zuordnung

Feature	Web (HTML/ARIA)	iOS (SwiftUI)	Android (Compose)
Primäres Label	aria-label / <label>	.accessibilityLabel()	contentDescription
Sekundärer Hinweis	aria-describedby	.accessibilityHint()	Modifier.semantics { stateDescription = ... }
Aktionsrolle	role="button"	.accessibilityAddTraits(.isButton)	Modifier.semantics { role = Role.Button }
Live-Updates	aria-live="polite"	.accessibilityLiveRegion(.polite)	Modifier.semantics { liveRegion = LiveRegionMode.Polite }

Beispiele

Web: Zugängliche Suche

<form role="search">
  <label for="search-input" class="sr-only">Produkte durchsuchen</label>
  <input type="search" id="search-input" placeholder="Suchen..." />
  <button type="submit" aria-label="Suche absenden">
    <svg aria-hidden="true">...</svg>
  </button>
</form>

iOS: Zugänglicher Aktionsbutton

Button(action: deleteItem) {
    Image(systemName: "trash")
}
.accessibilityLabel("Element löschen")
.accessibilityHint("Entfernt dieses Element dauerhaft aus Ihrer Liste")
.accessibilityAddTraits(.isButton)

Android: Zugänglicher Schalter

Switch(
    checked = isEnabled,
    onCheckedChange = { onToggle() },
    modifier = Modifier.semantics {
        contentDescription = "Benachrichtigungen aktivieren"
    }
)

Anti-Patterns – zu vermeiden

• Div-Buttons: Verwenden eines <div> oder <span> für ein Klickereignis ohne Hinzufügen einer Rolle und Tastaturunterstützung.
• Nur-Farbe-Bedeutung: Anzeigen eines Fehlers oder Status nur durch eine Farbänderung (z. B. roter Rand).
• Unkontrollierter modaler Fokus: Modale, die den Fokus nicht einschränken, sodass Tastaturnutzer im Hintergrund navigieren können, während das Modal geöffnet ist. Der Fokus muss eingeschränkt und über die Escape-Taste oder einen expliziten Schließen-Button verlassen werden können (WCAG SC 2.1.2).
• Redundanter Alternativtext: Verwenden von „Bild von..." oder „Foto von..." im Alternativtext (Screenreader kündigen die Rolle „Bild" bereits an).

Checkliste für Best Practices

• Interaktive Elemente erfüllen die Zielgröße von 24x24px (Web) oder 44x44pt (Nativ).
• Fokusindikatoren sind deutlich sichtbar und kontrastreich.
• Modale schränken den Fokus ein, während sie geöffnet sind, und geben ihn beim Schließen sauber frei (Escape-Taste oder Schließen-Button).
• Dropdowns und Menüs setzen den Fokus beim Schließen auf das auslösende Element zurück.
• Formulare bieten textbasierte Fehlervorschläge.
• Alle reinen Symbolschaltflächen haben ein beschreibendes Textlabel.
• Inhalte fließen bei skalierter Schrift korrekt um.

Referenzen

• WCAG 2.2 Richtlinien
• WAI-ARIA Authoring Practices
• iOS Accessibility Programming Guide
• iOS Human Interface Guidelines – Barrierefreiheit
• Android Accessibility Developer Guide

Verwandte Kompetenzen

• frontend-patterns
• design-system
• liquid-glass-design
• swiftui-patterns