Was sind WCAG (Web Content Accessibility Guidelines)?

Was sind die Web Content Accessibility Guidelines (WCAG)?

Die Web Content Accessibility Guidelines (WCAG) sind der internationale Standard für digitale Barrierefreiheit, veröffentlicht vom W3C durch die Web Accessibility Initiative (WAI). WCAG definiert, wie Websites, Web-Anwendungen und digitale Dokumente designt und gebaut werden müssen, damit Menschen mit Behinderungen sie wahrnehmen, bedienen, verstehen und navigieren können.

WCAG ist nicht nur Anleitung — es ist die technische Grundlage, auf die sich Barrierefreiheits-Gesetze weltweit beziehen. Der European Accessibility Act, die Americans with Disabilities Act (ADA)-Gerichtsfälle, Section 508 des U.S. Rehabilitation Act, die EU Web Accessibility Directive, das UK Equality Act, Kanadas ACA und Australiens DDA verweisen alle auf WCAG als de-facto-Definition von "barrierefrei".

Die vier POUR-Prinzipien

WCAG ist um vier grundlegende Prinzipien strukturiert, im Akronym POUR erfasst:

• Perceivable (Wahrnehmbar) — Nutzer müssen den Content durch ihre verfügbaren Sinne wahrnehmen können. Das bedeutet Text-Alternativen für Bilder, Untertitel für Video, ausreichenden Farbkontrast und Content, der auf verschiedene Arten präsentiert werden kann, ohne Bedeutung zu verlieren.
• Operable (Bedienbar) — Nutzer müssen das Interface bedienen können. Funktionalität muss via Tastatur verfügbar sein, Content darf keine Anfälle auslösen (kein Blinken mehr als 3 mal pro Sekunde), Nutzer müssen genug Zeit zum Lesen haben und Navigation muss vorhersagbar sein.
• Understandable (Verständlich) — Nutzer müssen sowohl den Content als auch die Bedienung des Interfaces verstehen. Text muss lesbar sein, Content muss in vorhersagbaren Wegen erscheinen und arbeiten und Nutzer müssen geholfen werden, Fehler zu vermeiden und zu korrigieren.
• Robust (Robust) — Content muss robust genug sein, mit aktuellen und zukünftigen User-Agents zu arbeiten, einschließlich Assistive Technologies. Code muss valide sein, ARIA muss korrekt genutzt werden und Komponenten müssen ihren Namen, ihre Rolle und ihren Wert an Assistive Tech kommunizieren.

Die drei Konformitätsstufen

WCAG definiert drei Konformitätsstufen, die zunehmende Barrierefreiheit ausdrücken:

Stufe A — Minimum (der Boden)

Die grundlegendsten Anforderungen. Stufe A zu verfehlen bedeutet, Content ist für manche Gruppen behinderter Nutzer unbenutzbar. Beispiele: jedes <img> braucht Alt-Text, Video braucht Untertitel, Tastatur-Navigation muss funktionieren. Keine Site sollte ohne Stufe-A-Compliance shippen.

Stufe AA — das rechtliche/praktische Ziel

Die meisten Barrierefreiheits-Gesetze und Verordnungen erfordern Stufe AA. Fügt nuancierte Kriterien hinzu: 4,5:1-Kontrastverhältnis für normalen Text, Untertitel für Live-Video, Fokus-Indikatoren sichtbar, Zielgrößen erfüllen Minima (24×24 in WCAG 2.2). Stufe AA ist das praktische Ziel für Produktions-Sites.

Stufe AAA — der erweiterte Standard

Die höchste Stufe, oft unpraktisch für ganze Sites, weil manche Kriterien radikale Reorganisation erfordern. AAA erfordert: 7:1-Kontrast, Gebärdensprach-Übersetzung für Video, keine Zeitlimits irgendwo, Plain-Language-Lesen auf untersekundärem Niveau. Die meisten Sites zielen AAA nur für spezifische High-Stakes-Flows an (Anmeldung, Checkout, Behördenformulare), nicht site-weit.

WCAG-Versions-Timeline

• WCAG 1.0 (1999) — Original, jetzt veraltet.
• WCAG 2.0 (2008) — Führte die POUR-Prinzipien ein. Noch rechtlich gültig in vielen Jurisdiktionen.
• WCAG 2.1 (2018) — Fügte 17 Erfolgskriterien für Mobile, Low Vision und kognitive Behinderungen hinzu. Die meistzitierte Version in aktuellem Recht.
• WCAG 2.2 (Oktober 2023) — Fügt 9 Erfolgskriterien für kognitive Barrierefreiheit, Mobile und Low-Vision-Nutzer hinzu. Bemerkenswerte Ergänzungen: Zielgrößen-Minimum (Stufe AA, 24×24px), Fokus-Erscheinung erweitert, barrierefreie Authentifizierung, Drag-Bewegungen-Alternative.
• WCAG 3.0 (in Entwicklung) — Eine komplette Restrukturierung statt eines inkrementellen Updates. Nutzt Ergebnis-basiertes Scoring statt Pass/Fail-Kriterien. Noch nicht stabil; Produktions-Teams sollten weiterhin WCAG 2.2 anvisieren.

Die 13 am häufigsten verfehlten WCAG-Kriterien (nach Häufigkeit)

Laut WebAIM-Million-2024-Report verfehlen diese Kriterien auf den meisten Homepages:

1. 1.4.3 Kontrast (Minimum) — 81% der Seiten haben Niedrig-Kontrast-Text. Das größte einzelne Barrierefreiheits-Problem im Web.
2. 1.1.1 Non-text Content — 54% der Seiten haben Bilder ohne Alt-Text.
3. 4.1.2 Name, Role, Value — 44% der Seiten haben Form-Inputs ohne richtige Labels oder Buttons ohne barrierefreie Namen.
4. 2.4.4 Link Purpose — 45% der Seiten haben mehrdeutigen Link-Text ("hier klicken", "mehr lesen").
5. 1.3.1 Info and Relationships — 30% haben unzulässige Heading-Struktur oder unbeschriftete Form-Felder.
6. 3.1.1 Language of Page — 17% fehlt das lang-Attribut auf <html>.
7. 4.1.1 Parsing — Duplicate-IDs, ungeschlossene Tags etc. (Hinweis: in WCAG 2.2 entfernt.)
8. 2.4.6 Headings and Labels — Headings, die ihr Thema nicht beschreiben.
9. 1.4.5 Images of Text — Text als Bild gerendert statt als auswählbarer Text.
10. 2.4.7 Focus Visible — Custom-CSS versteckt den Fokus-Ring, ohne ihn zu ersetzen.
11. 3.3.2 Labels or Instructions — Form-Felder ohne Labels oder mit dem Placeholder-als-Label-Antipattern.
12. 1.4.4 Resize Text — Layout bricht beim Zoomen von Text.
13. 2.5.3 Label in Name — Sichtbarer Label-Text passt nicht zum barrierefreien Namen.

Diese 13 Issues zu fixen, addressiert 95%+ der Barrierefreiheits-Beschwerden auf den meisten Sites.

WCAG-Konformitäts-Nachweis: VPAT, ACR, Accessibility-Audits

Deine WCAG-Compliance zu dokumentieren, wird zunehmend von Enterprise-Procurement-Teams, Behörden-RFPs und Barrierefreiheits-Klagen gefordert. Der Standard-Dokumentations-Flow:

• VPAT — das leere Template, bereitgestellt von ITI. Du füllst es für dein Produkt aus.
• ACR (Accessibility Conformance Report) — der ausgefüllte VPAT. "Wir haben einen ACR" bedeutet "wir haben einen VPAT ausgefüllt".
• Third-Party-Audit — ein zertifizierter Accessibility-Berater testet dein Produkt manuell + mit Assistive Tech und produziert einen Remediation-Report.
• Jährliches Re-Audit — die meisten Enterprise-Procurement erfordert, dass VPATs/Audits nicht älter als 12 Monate sind.

Häufige WCAG-Implementierungs-Fehler

• Barrierefreiheit als Final-Step-Checklist behandeln. WCAG ist am teuersten, wenn am Ende drangeschraubt. Backe es ins Design (Farbsysteme, Fokus-States), Komponenten (semantisches HTML, richtige Labels) und CI (axe-core, Pa11y, Lighthouse).
• Sich allein auf automatisiertes Testen verlassen. Automatisierte Tools fangen 30-40% der WCAG-Verletzungen. Die anderen 60-70% (sinnvoller Alt-Text, logische Tab-Ordnung, Screenreader-Erfahrung) erfordern manuelles Testen mit echter Assistive Tech.
• Rechtliche Compliance mit nutzbarer Barrierefreiheit verwechseln. Automatisierte Checks zu bestehen, ist nicht dasselbe wie barrierefrei zu sein. Teste mit Screenreadern (NVDA, JAWS, VoiceOver), Tastatur-only-Navigation und idealerweise Nutzern mit Behinderungen.
• ARIA, wo semantisches HTML funktioniert. Die erste Regel von ARIA: nutze ARIA nicht. Natives <button>, <label> und <nav> schlägt Custom-role="button" auf <div> 100% der Zeit.
• Kognitive Barrierefreiheit ignorieren. WCAG 2.2 fügte aus einem Grund kognitive Kriterien hinzu. Plain-Language, vorhersagbare Patterns und hilfreiche Fehlerwiederherstellung sind nicht optional.
• Den Kontrast-Checker verspotten. 4,5:1 ist nicht exzessiv — es ist der Boden für Nutzer mit milder visueller Beeinträchtigung. "Sieht für mich okay aus" ist kein Kontrast-Test.

FAQ: WCAG

Ist WCAG rechtlich erforderlich?

In vielen Jurisdiktionen, ja. Der European Accessibility Act (effektiv Juni 2025) erfordert WCAG 2.1 AA. Die ADA in den USA ist von Bundesgerichten interpretiert worden, WCAG-Konformität zu erfordern. Section 508 des Rehabilitation Act mandiert WCAG 2.0 AA für U.S.-Bundesbehörden. Prüfe lokales Recht für spezifische Verpflichtungen.

Welche WCAG-Version sollte ich 2026 anvisieren?

WCAG 2.2 Stufe AA ist das aktuelle beste Ziel. Es ist die neueste stabile Version mit breiter regulatorischer Adoption. WCAG 3.0 ist noch in Entwicklung; die meisten Teams sollten es noch nicht anvisieren.

Wie weiß ich, ob meine Site WCAG erfüllt?

Drei Schichten: (1) automatisierte Tools (axe DevTools, WAVE, Lighthouse) fangen die einfachen Verletzungen; (2) manuelles Testen mit Tastatur und Screenreadern fängt operative Issues; (3) Third-Party-Audit fängt alles andere und produziert einen ACR.

Wieviel kostet WCAG-Compliance?

Stark variabel. Eine einfache Marketing-Site kann für 5K-15K $ Design + Dev-Zeit auf AA gebracht werden. Eine große Web-App könnte 50K-500K $ Remediation brauchen. Barrierefreiheit von Anfang an einzubauen, fügt ~10-15% zu den Entwicklungskosten hinzu; sie später anzuschrauben fügt 200-400% hinzu.

Was ist der Unterschied zwischen WCAG und ADA?

WCAG ist der technische Standard. ADA ist U.S.-Recht (Americans with Disabilities Act). U.S.-Gerichte haben wiederholt festgestellt, dass Public-Accommodation-Websites barrierefrei sein müssen, und sie nutzen WCAG als technische Definition von "barrierefrei". Andere Länder-Gesetze zitieren WCAG ähnlich.

Deckt WCAG Mobile Apps ab?

WCAG wurde für Web-Content designed, aber wird breit auf Mobile Apps angewendet. WCAG 2.1 fügte Mobile-spezifische Kriterien hinzu (Orientierung, Motion-Actuation, Zielgrößen) und WCAG 2.2 ging weiter. Native iOS/Android-Apps haben auch plattform-spezifische Guidelines (Apple Accessibility, Google Accessibility), die WCAG ergänzen.

Wie LoadFocus in Accessibility-Testing passt

Barrierefreiheit geht Hand in Hand mit Performance — langsame Seiten beeinträchtigen Nutzer mit Behinderungen unverhältnismäßig (ältere Geräte, Assistive Tech mit Overhead). LoadFocus-Website-Speed-Testing validiert, dass deine barrierefreie Site auch auf Geräten schnell lädt. Synthetisches Monitoring fängt Barrierefreiheits-Regressionen, wenn du shippst — einschließlich verlorenem Alt-Text, kaputten Fokus-States und Kontrast-Failures, die durch CSS-Änderungen eingeführt werden.