WCAG — was ist das, Web Content Accessibility Guidelines und AA-Stufen

Was ist WCAG?

WCAG (Web Content Accessibility Guidelines) ist eine Reihe von Empfehlungen zur Sicherstellung der Barrierefreiheit von Webinhalten für Menschen mit Behinderungen. Der Standard wird seit 1999 von der W3C Web Accessibility Initiative (WAI) entwickelt. WCAG umfasst blinde und sehbehinderte, gehörlose und schwerhörige Menschen, Personen mit Mobilitätseinschränkungen, Sprach- und kognitiven Beeinträchtigungen sowie ältere Nutzer mit altersbedingten Veränderungen.

Die erste Version WCAG 1.0 wurde 1999 veröffentlicht und enthielt 14 Leitprinzipien. WCAG 2.0 (2008) wurde technologieneutral und auf HTML, PDF, Multimedia und mobile Anwendungen anwendbar. WCAG 2.1 (2018) ergänzte Kriterien für mobile Geräte und Touch-Eingabe. WCAG 2.2 (2023) ist die aktuelle Version mit neuen Kriterien für Animation und Fokus. WCAG ist kein Gesetz, aber viele Länder verweisen in ihrer Gesetzgebung darauf.

GOST R 52872-2019 in Russland, der European Accessibility Act in der EU und Section 508 in den USA — alle fordern WCAG-AA-Konformität. Für Unternehmens- und Regierungswebsites ist WCAG AA ein verbindlicher Standard, dessen Nichteinhaltung zu Klagen führt. Laut UsableNet (2024) wurden in den USA über 12.000 Klagen zur Web-Barrierefreiheit eingereicht.

WCAG-Versionen: Vergleich

Rechtliche Folgen der Nichteinhaltung

Die Nichteinhaltung von WCAG birgt erhebliche Risiken. 2025 trat der European Accessibility Act (EAA) in Kraft, der WCAG 2.1 AA für alle öffentlichen Websites und mobilen Anwendungen in der EU vorschreibt. Bußgelder können bis zu 5% des Jahresumsatzes des Unternehmens betragen. Die durchschnittliche Vergleichssumme in US-Klagen beträgt $25.000–$50.000. Accessibility-Audits sollten in jeder Entwicklungsphase durchgeführt werden, nicht nur vor der Veröffentlichung.

Vier Prinzipien von WCAG: POUR

POUR ist ein Akronym für vier WCAG-Prinzipien: Perceivable (Wahrnehmbarkeit), Operable (Bedienbarkeit), Understandable (Verständlichkeit), Robust (Robustheit). Jedes Prinzip enthält Richtlinien, und die Richtlinien enthalten testbare Erfolgskriterien. WCAG 2.2 hat 13 Richtlinien und 86 Erfolgskriterien. Jedes Kriterium hat die Stufe A, AA oder AAA.

Perceivable — Wahrnehmbarkeit

Das Perceivable-Prinzip verlangt, dass Inhalte in einer Form dargestellt werden, die der Nutzer wahrnehmen kann. Richtlinien: 1.1 Text Alternatives (Textalternativen), 1.2 Time-based Media (Untertitel, Transkripte), 1.3 Adaptable (Inhalte ohne Verlust bei Formatänderung), 1.4 Distinguishable (Kontrast 4.5:1, Farbe, Ton). Das Schlüsselkriterium 1.4.3 Contrast Minimum (AA) ist das am häufigsten verletzte: 86% der Seiten entsprechen ihm laut WebAIM nicht.

Operable — Bedienbarkeit

Das Operable-Prinzip verlangt die Bedienbarkeit der Schnittstelle. Richtlinien: 2.1 Keyboard Accessible, 2.2 Enough Time, 2.3 Seizures, 2.4 Navigable, 2.5 Input Modalities. Kriterium 2.1.1 Keyboard (A) ist eines der kritischsten: Alle Funktionen müssen über die Tastatur ohne Maus zugänglich sein. Modalfenster, die nur durch Klicken schließen, Dropdowns ohne Tastaturnavigation — typische Verstöße.

Understandable — Verständlichkeit

Das Understandable-Prinzip verlangt die Verständlichkeit von Inhalten und Schnittstelle. Richtlinien: 3.1 Readable, 3.2 Predictable, 3.3 Input Assistance. Kriterium 3.3.4 Error Prevention ist besonders wichtig für Finanz- und Medizinanwendungen: Vermeidung schwerwiegender Folgen von Eingabefehlern. Kriterium 3.2.6 Consistent Help (neu in WCAG 2.2) verlangt, dass Hilfeschaltflächen an denselben Stellen sind.

Robust — Robustheit

Das Robust-Prinzip verlangt Kompatibilität mit assistiven Technologien. Richtlinie 4.1 Compatible mit Schlüsselkriterium 4.1.2 Name, Role, Value (A): Jede UI-Komponente muss programmgesteuert ermittelbare Name, Rolle und Zustand haben. ARIA-Attribute (role, aria-label, aria-expanded) sind das Hauptwerkzeug. Ohne sie können Screenreader nicht feststellen, ob ein Element ein Button, Link oder Tab ist.

WCAG-Prinzipien-Tabelle

WCAG-Konformitätsstufen: A, AA, AAA

WCAG definiert drei Stufen: A (minimal), AA (Standard) und AAA (maximal). Stufe A ist das verbindliche Minimum: Ohne sie ist der Inhalt für einige Nutzergruppen unzugänglich. AA beseitigt die wichtigsten Barrieren. AAA ist der höchste Standard, kann aber nicht für alle Inhalte erreicht werden (z. B. sind manche Gebärdensprachen oder Audiotranskriptionen nicht immer realisierbar).

Stufe A (30 Kriterien): Textalternativen, Tastaturbedienbarkeit, ausreichende Zeit, kein Flackern über 3 Hz. Stufe AA (+24 Kriterien): Kontrastverhältnis 4.5:1, Untertitel für Video, Textvergrößerung bis 200%, klarer Tastaturfokus. Stufe AAA (+32 Kriterien): Kontrastverhältnis 7:1, Gebärdensprache, Deaktivierung von Animationen (2.3.3), Audiotranskription. Für Regierungswebsites ist AA ausreichend.

WCAG-Audit-Prozess

Ein WCAG-Accessibility-Audit umfasst: automatisierte Tests (axe DevTools, WAVE, Lighthouse — finden 30–40% der Fehler), manuelle Tastatur- und Screenreader-Tests (VoiceOver, TalkBack, NVDA), Experten-Audit für komplexe Kriterien und Benutzertests mit Menschen mit Behinderungen. Der Audit-Bericht sollte die Konformitätsstufe und eine Liste der Nichtkonformitäten für jedes Kriterium enthalten.

Neuerungen in WCAG 2.2

WCAG 2.2 hat 9 neue Kriterien hinzugefügt. Wichtigste: 2.4.11 Focus Appearance (AA) — Fokusindikator >= 2px mit 3:1-Kontrast, 2.5.8 Target Size Minimum (AA) — Touch-Ziel mindestens 24x24 Pixel, 3.3.7 Accessible Authentication (AA) — Authentifizierung ohne CAPTCHA. Kriterium 2.3.3 Animation from Interactions (AAA) — deaktivierbare Animation oder nicht länger als 5 Sekunden.

Focus Appearance ist die wichtigste Änderung. Bisher war outline: none ohne Ersatz ein Verstoß, aber es gab keine klaren Anforderungen. WCAG 2.2 legte fest: Dicke >= 2px, Kontrast 3:1 zum Hintergrund, Indikatorfläche mindestens so groß wie die Elementfläche. Für benutzerdefinierte Buttons mit border-radius verwenden Sie box-shadow statt outline.

Focus Appearance in CSS

/* WCAG 2.2 Focus Appearance (2.4.11 AA) */
:focus-visible {
    outline: 3px solid #0066CC;
    outline-offset: 2px;
}

.button:focus-visible {
    outline: none;
    box-shadow:
        0 0 0 3px #FFFFFF,
        0 0 0 6px #0066CC;
}

@media (prefers-color-scheme: dark) {
    :focus-visible { outline-color: #66B2FF; }
}

@media (prefers-contrast: more) {
    :focus-visible { outline: 4px solid #000; outline-offset: 3px; }
}

Die Gestaltung von :focus-visible gewährleistet die Einhaltung des Kriteriums Focus Appearance. Eine Alternative über box-shadow funktioniert für Elemente mit border-radius. Dunkles Design und High Contrast passen die Fokusfarben an.

Accessible Authentication

Kriterium 3.3.7 Accessible Authentication (AA) ist eine der meistdiskutierten Neuerungen. CAPTCHA mit Objekterkennung, Puzzles, Schieberegler-Ziehen — jetzt ein Verstoß, wenn es keine Alternative gibt. Zulässige Methoden: OTP per E-Mail/SMS, Biometrie (Face ID, Touch ID), QR-Codes, Magic Link. Dies erleichtert nicht nur Menschen mit kognitiven Beeinträchtigungen, sondern allen Nutzern das Leben.

WCAG für mobile Anwendungen

WCAG gilt für native iOS- und Android-Anwendungen. Die vier POUR-Prinzipien decken mobile Schnittstellen vollständig ab. Spezifische Kriterien: 2.5.1 Pointer Gestures (Gesten ohne hohe Präzision), 2.5.2 Pointer Cancellation (Abbruch versehentlicher Berührung), 2.5.3 Label in Name (Schaltflächentext stimmt mit Accessibility-Label überein). iOS verwendet UIKit/UIAccessibility, Android verwendet AccessibilityService und ContentDescription.

Am häufigsten in mobilen Anwendungen verletzt: 1.1.1 Non-text Content — Symbole ohne contentDescription, 2.4.3 Focus Order — falsche Navigationsreihenfolge, 2.5.8 Target Size — Schaltflächen kleiner als 24x24dp, 1.4.3 Contrast — Text auf Hintergrundbildern. iOS bietet Accessibility Inspector in Xcode, Android bietet Accessibility Scanner für automatisierte Audits.

WCAG-konformer SwiftUI-Code

import SwiftUI

struct AccessibleButton: View {
    let action: () -> Void
    let title: String
    let icon: String

    var body: some View {
        Button(action: action) {
            HStack {
                Image(systemName: icon)
                Text(title)
            }
            .padding(16)
            .background(Color.blue)
            .foregroundColor(.white)
            .cornerRadius(12)
            .frame(minWidth: 48, minHeight: 48)
        }
        .accessibilityLabel(title)
        .accessibilityHint("Klicken Sie für Aktion")
        .accessibilityAddTraits(.isButton)
    }
}

struct AccessibleForm: View {
    @State private var email = ""

    var body: some View {
        VStack(spacing: 16) {
            VStack(alignment: .leading) {
                Text("E-Mail")
                TextField("E-Mail eingeben", text: $email)
                    .textContentType(.emailAddress)
                    .keyboardType(.emailAddress)
                    .autocapitalization(.none)
                    .accessibilityLabel("E-Mail-Eingabefeld")
                    .accessibilityHint("E-Mail-Adresse eingeben")
            }
            AccessibleButton(
                action: { },
                title: "Senden",
                icon: "paperplane.fill"
            )
        }
        .padding()
    }
}

SwiftUI-Komponenten mit accessibilityLabel, accessibilityHint und minWidth/minHeight >= 48pt gewährleisten die Einhaltung von WCAG 2.5.8 (Target Size) und 2.5.3 (Label in Name). Verwenden Sie Xcode Accessibility Inspector zur Überprüfung von VoiceOver-Fokus, Navigationsreihenfolge und Touch-Zielgrößen. Ähnliche Anforderungen gelten für Jetpack Compose über Modifier.semantics.