Barrierefreiheit (WCAG 2.2)

Was macht Barrierefreiheit (WCAG 2.2)?

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

Wann verwenden

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

Kernkonzepte

• POUR-Prinzipien: Die Grundlage von WCAG (Wahrnehmbar, Bedienbar, Verständlich, Robust).
• Semantische Zuordnung: Verwendung nativer Elemente anstelle generischer Container, um eine eingebaute Barrierefreiheit zu gewährleisten.
• Accessibility Tree: Die Darstellung der UI, die assistive Technologien tatsächlich „lesen“.
• Fokusverwaltung: Steuerung der Reihenfolge und Sichtbarkeit des Tastatur-/Screenreader-Cursors.
• Beschriftung und Hinweise: Bereitstellung von Kontext durch aria-label, accessibilityLabel und contentDescription.

Funktionsweise

Schritt 1: Identifizieren der Komponentenrolle

Bestimmen Sie den funktionalen Zweck (z. B. Ist dies ein Button, ein Link oder ein Tab?). Verwenden Sie das semantischste native Element, bevor Sie auf benutzerdefinierte Rollen zurückgreifen.

Schritt 2: Definieren wahrnehmbarer 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 hinzu (Bilder, Symbole).
• Implementieren Sie responsives Reflow (bis zu 400 % Zoom ohne Funktionsverlust).

Schritt 3: Implementieren bedienbarer 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 einen sichtbaren Fokusindikator aufweisen (SC 2.4.11).
• Bieten Sie Einzelzeigeralternativen für Ziehbewegungen.

Schritt 4: Sicherstellen verständlicher Logik

• 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 robuster Kompatibilität

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

Architekturdiagramm zur Barrierefreiheit

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

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

Plattformübergreifendes Mapping

Merkmal	Web (HTML/ARIA)	iOS (SwiftUI)	Android (Compose)
Primäre Bezeichnung	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: Barrierefreie Suche

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

iOS: Barrierefreier Aktionsbutton

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

Android: Barrierefreier Schalter

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

Zu vermeidende Anti-Patterns

• 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. ein rotes Umranden).
• Unbegrenzter modaler Fokus: Modale, die den Fokus nicht einschließen, sodass Tastaturnutzer Hintergrundinhalte navigieren können, während das Modal geöffnet ist. Der Fokus muss eingeschlossen und über die Escape-Taste oder eine explizite Schaltfläche schließbar sein (WCAG SC 2.1.2).
• Redundanter Alternativtext: Verwenden von „Bild von...“ oder „Abbildung von...“ im Alt-Text (Screenreader kündigen die Rolle „Bild“ bereits an).

Best Practices Checkliste

• Interaktive Elemente erfüllen die Zielgröße von 24x24px (Web) oder 44x44pt (nativ).
• Fokusindikatoren sind deutlich sichtbar und kontrastreich.
• Modale schließen den Fokus ein, während sie geöffnet sind, und geben ihn beim Schließen sauber frei (Escape-Taste oder Schaltfläche).
• Dropdowns und Menüs setzen den Fokus nach dem Schließen auf das auslösende Element zurück.
• Formulare bieten textbasierte Fehlervorschläge.
• Alle nur-symbolischen Buttons haben eine beschreibende Textbezeichnung.
• Inhalte fließen ordnungsgemäß um, wenn die Textgröße skaliert wird.

Referenzen

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

Verwandte Skills

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