Barrierefreiheit (WCAG 2.2)

Was macht Barrierefreiheit (WCAG 2.2)?

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

Verwendung

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

Kernkonzepte

• POUR-Prinzipien: Die Grundlage der WCAG (Wahrnehmbar, Bedienbar, Verständlich, Robust).
• Semantische Abbildung: Verwendung nativer Elemente anstelle generischer Container für integrierte Barrierefreiheit.
• Accessibility Tree: Die Darstellung der UI, die assistive Technologien tatsächlich „lesen".
• Fokus-Management: Steuerung der Reihenfolge und Sichtbarkeit des Tastatur-/Screenreader-Cursors.
• Beschriftung & Hinweise: Kontextbereitstellung 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 sicher, dass der Textkontrast 4.5:1 (normal) oder 3:1 (groß/UI) beträgt.
• Fügen Sie Textalternativen für nicht-textuelle Inhalte hinzu (Bilder, Symbole).
• Implementieren Sie responsives Reflow (bis zu 400 % Zoom ohne Funktionsverlust).

Schritt 3: Implementieren bedienbarer Steuerelemente

• Stellen Sie eine Mindestgröße von 24x24 CSS-Pixeln für die Zielfläche sicher (WCAG 2.2 SC 2.5.8).
• Überprüfen Sie, ob alle interaktiven Elemente per Tastatur erreichbar sind und eine sichtbare Fokus-Anzeige haben (SC 2.4.11).
• Bieten Sie Einzelzeigeralternativen für Ziehbewegungen an.

Schritt 4: Sicherstellen verständlicher Logik

• Verwenden Sie konsistente Navigationsmuster.
• Geben Sie beschreibende Fehlermeldungen und Korrekturvorschläge an (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.

Diagramm zur Barrierefreiheitsarchitektur

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übergreifende Zuordnung

Funktion	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: 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"
    }
)

Anti-Patterns, die vermieden werden sollten

• Div-Buttons: Verwendung eines <div> oder <span> für ein Klickereignis, ohne eine Rolle und Tastaturunterstützung hinzuzufügen.
• Farbe als einzige Bedeutung: Anzeigen eines Fehlers oder Status nur durch eine Farbänderung (z. B. einen roten Rand).
• Nicht eingeschränkter Modal-Fokus: Modale, die den Fokus nicht einschließen, sodass Tastaturbenutzer den Hintergrundinhalt navigieren können, während das Modal geöffnet ist. Der Fokus muss eingeschlossen und über die Escape-Taste oder einen expliziten Schließen-Button verlassen werden können (WCAG SC 2.1.2).
• Redundanter Alternativtext: Verwendung von „Bild von..." oder „Foto von..." im Alt-Text (Screenreader geben die Rolle „Bild" bereits bekannt).

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 schließen den Fokus ein, während sie geöffnet sind, und geben ihn sauber frei, wenn sie geschlossen werden (Escape-Taste oder Schließen-Button).
• 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-Symbol-Buttons haben ein beschreibendes Textlabel.
• Inhalte führen bei Skalierung des Textes ein korrektes Reflow durch.

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