WCAG (Web Content Accessibility Guidelines)
Definition: WCAG (Web Content Accessibility Guidelines; Richtlinien für barrierefreie Web-Inhalte) sind die international maßgeblichen technischen und gestalterischen Richtlinien des W3C (World Wide Web Consortium; gegründet 1994; Tim Berners-Lee; Cambridge; MA) für die Barrierefreiheit von Web-Inhalten – entwickelt durch die Web Accessibility Initiative (WAI; seit 1997). WCAG-Grundprinzipien (POUR-Modell): Perceivable (Wahrnehmbar; alle Inhalte für alle Sinne zugänglich; Alt-Texte; Untertitel; Kontrast); Operable (Bedienbar; alle Funktionen per Tastatur; ohne Zeitdruck; ohne Anfalls-Risiko); Understandable (Verständlich; klare Sprache; vorhersehbares Verhalten; Fehler-Hilfe); Robust (Robust; kompatibel mit assistiven Technologien; Screen-Readern; Braille-Displays). WCAG-Konformitätsstufen: Level A (25 Erfolgskriterien; absolute Mindestanforderung; ohne diese ist Inhalt für bestimmte Nutzergruppen vollständig unzugänglich); Level AA (13 zusätzliche Kriterien; 38 gesamt; internationaler gesetzlicher Standard; EU-Pflicht seit 2018 für öffentliche Stellen; für private Unternehmen ab 2025 in EU); Level AAA (28 weitere Kriterien; 66 gesamt; optionale Exzellenz; für kritische Systeme wie Gesundheit; Bildung; Behörden empfohlen). WCAG-Versionen: WCAG 2.0 (W3C Empfehlung; 11. Dezember 2008); WCAG 2.1 (W3C Empfehlung; 5. Juni 2018; +17 Kriterien; Fokus Mobile und kognitive Einschränkungen); WCAG 2.2 (W3C Empfehlung; 5. Oktober 2023; +9 neue Kriterien; entfernt 4.1.1 Parsing; aktueller gesetzlicher Standard); WCAG 3.0 (in Entwicklung; AGWG; neues Scoring-System; nicht vor 2026 Empfehlung).
Erläuterung
Die Web Accessibility Initiative (WAI; W3C; gegründet 1997) unter der Leitung von Gregg Vanderheiden (University of Wisconsin-Madison; Madison; WI; Trace Research and Development Center; gegründet 1971; Pionier der Assistiven Technologien) und Judy Brewer (W3C; WAI-Direktor) entwickelte WCAG als technische Grundlage für gesetzliche Barrierefreiheits-Anforderungen: die erste WCAG-Version (1.0; 5. Mai 1999) enthielt 14 Richtlinien und 65 Prüfpunkte; war noch stark HTML-spezifisch; WCAG 2.0 (2008) abstrahierte die Richtlinien von spezifischen Technologien auf technologie-neutrale Prinzipien um zukünftige Web-Technologien (JavaScript-Apps; PDF; Flash; Mobile) abzudecken; WCAG 2.0 wurde zur Grundlage aller folgenden gesetzlichen Regelungen weltweit. Das POUR-Modell (Perceivable; Operable; Understandable; Robust) als konzeptionelle Grundlage geht auf Forschung von Vanderheiden und dem Trace Center zurück sowie auf John Slatin (University of Texas at Austin; Austin; TX; «Creating Accessibility Guidelines for E-Content», World Wide Web Consortium Working Draft Contribution, 2002); POUR strukturiert Barrierefreiheit nicht nach Behinderungsart sondern nach funktionalem Zugangs-Typ; ein Screen-Reader-Nutzer braucht «Perceivable»-Konformität (Alt-Texte); ein motorisch eingeschränkter Nutzer braucht «Operable»-Konformität (Tastatur-Navigation); POUR machte WCAG-Konformität planbar und testbar. Bruce Bailey (Access Board; Washington; D.C.) und Makoto Ueki (Ibaraki University; Mito; Japan) sowie weitere AGWG-Mitglieder (Accessibility Guidelines Working Group) entwickelten WCAG 2.1 (2018) mit 17 neuen Erfolgskriterien: Mobile-Erweiterungen (2.5.1–2.5.6: Zeiger-Gesten; Zeiger-Abbruch; Label-in-Name; Bewegungs-Aktivierung); kognitive Erweiterungen (1.3.4 Orientierung; 1.4.10 Reflow für 400% Zoom; 1.4.11 Non-Text Contrast; 1.4.12 Text Spacing; 1.4.13 Content on Hover or Focus); WCAG 2.1 Level AA wurde 2018 zur Anforderung für öffentliche EU-Stellen (Richtlinie 2016/2102/EU; «Web Accessibility Directive»). WCAG 2.2 (Oktober 2023) fügte 9 neue Erfolgskriterien hinzu mit Fokus auf kognitive Zugänglichkeit und mobile Bedienung: 2.4.11 Focus Not Obscured (Fokus-Indikator nicht vollständig verdeckt); 2.4.12 Focus Not Obscured Enhanced (AAA); 2.4.13 Focus Appearance (Fokus sichtbar; mindestens 3:1 Kontrast; 2px Umrandung); 2.5.7 Dragging Movements (Alternative ohne Drag); 2.5.8 Target Size Minimum (mindestens 24×24px für klickbare Ziele); 3.2.6 Consistent Help; 3.3.7 Redundant Entry (eingegebene Daten nicht erneut eingeben müssen); 3.3.8 Accessible Authentication Minimum; 3.3.9 Accessible Authentication (No Exception; AAA); WCAG 2.2 entfernte Erfolgskriterium 4.1.1 Parsing (da moderne Browser HTML-Fehler tolerieren); EU European Accessibility Act (EAA; Richtlinie 2019/882) mit Umsetzungsfrist 28. Juni 2025 für private Unternehmen verpflichtet zu WCAG 2.1 AA-Konformität für alle B2C-digitalen Produkte und Services. Lainey Feingold (Disability Rights Advocate; Oakland; CA; «Structured Negotiation», ABA Publishing, 2015) dokumentierte wie die juristische Durchsetzung von WCAG-Anforderungen (insbesondere ADA in den USA; Americans with Disabilities Act 1990; durch Department of Justice-Richtlinien auf Web ausgeweitet) zu einer Welle von Accessibility-Klagen gegen Unternehmen führte: allein in den USA wurden 2023 über 4.600 Federal-Accessibility-Klagen eingereicht (Seyfarth Shaw Law Firm; Annual ADA Title III Report 2023); die Mehrzahl betraf fehlende Alt-Texte; Keyboard-Navigation-Probleme und CAPTCHA-Barrieren.
WCAG-Erfolgskriterien und Prüfmethoden
- POUR-Prinzip und wichtigste Level-AA-Kriterien: Perceivable (Wahrnehmbar): 1.1.1 Non-Text Content (A): jedes Bild; Button-Icon; Diagramm braucht Alternativtext; Dekorations-Bilder: alt=""; 1.2.1–1.2.3 Zeitbasierte Medien (A/AA): Videos mit Untertiteln; Transkripte; Audio-Beschreibungen; 1.3.1 Info and Relationships (A): HTML-Semantik (h1-h6; lists; tables mit Headern); ARIA wenn HTML nicht ausreicht; 1.4.3 Contrast (Minimum) (AA): normaler Text ≥ 4,5:1; Großtext ≥ 3:1; 1.4.4 Resize Text (AA): Text auf 200% skalierbar ohne Inhaltsverlust; 1.4.10 Reflow (AA): bei 400% Zoom kein horizontales Scrollen (Responsive-Design-Anforderung); 1.4.11 Non-Text Contrast (AA; neu in 2.1): UI-Komponenten (Buttons; Formularfelder) und grafische Objekte ≥ 3:1 Kontrast zum Hintergrund; 1.4.12 Text Spacing (AA; neu in 2.1): Text bleibt lesbar bei gesteigertem Zeilen-/Buchstaben-/Wortabstand; Operable (Bedienbar): 2.1.1 Keyboard (A): alle Funktionen per Tastatur; 2.1.2 No Keyboard Trap (A): keine Keyboard-Fallen; 2.4.1 Bypass Blocks (A): Skip-Links; 2.4.3 Focus Order (A): logische Tab-Reihenfolge; 2.4.4 Link Purpose (A): Linktext beschreibt Ziel; 2.4.7 Focus Visible (AA): Fokus sichtbar; 2.5.8 Target Size (AA; WCAG 2.2): mindestens 24×24 CSS-Pixel
- Automatisierte und manuelle Prüfmethoden: Automatisierte Prüftools (erkennen ~30–40% aller WCAG-Fehler; Scott O'Hara/Adrian Roselli: manuelle Tests unersetzbar): axe DevTools (Deque Systems; Herndon; VA; 1997; Marktführer; Browser-Extension Chrome/Firefox; kostenlos; axe-core als Open-Source-Basis für alle anderen Tools; integriert in Playwright; Jest; Storybook); WAVE (WebAIM; Utah State University; Logan; UT; 2001; wave.webaim.org; kostenlos; visuelles Overlay; für Stakeholder-Demos gut geeignet); Lighthouse Accessibility Audit (Google; Chrome DevTools; PageSpeed Insights; CI-integrierbar; Score 0–100; basiert auf axe-core); Pa11y (Node.js; CLI; Open Source; npm install pa11y; CI-Pipeline-Integration); Silktide (kommerziell; Enterprise; sitemapsweite Analyse); Manuelle Prüfmethoden (restliche 60–70%): Tastaturnavigation-Test: alle interaktiven Elemente per Tab erreichbar; logische Reihenfolge; sichtbarer Fokus; Focus-Trap bei Modals; Skip-Link vorhanden; Screen-Reader-Test: NVDA + Firefox (Windows; kostenlos; NVDA.org); JAWS (Windows; Freedom Scientific; kommerziell; Marktführer Enterprise); VoiceOver (iOS/macOS; Apple; integriert; Ctrl+Option+U für Seitenübersicht); TalkBack (Android; Google; integriert); wichtig: Bedienbarkeit prüfen; nicht nur ob der Reader etwas vorliest; Farbkontrast-Prüfung: Colour Contrast Analyser (TPGi; kostenlos; Windows/Mac; pipette für beliebige Farben auf dem Bildschirm); WebAIM Contrast Checker; Browser DevTools (Chrome Accessibility Panel zeigt Kontrast direkt im Inspector)
- ARIA und HTML-Semantik: WAI-ARIA (Accessible Rich Internet Applications; W3C; ARIA 1.2 2023; James Nurthen/Valerie Young als Co-Chairs ARIA-WG): ARIA erweitert HTML-Semantik für komplexe JavaScript-Widgets die kein natives HTML-Äquivalent haben; ARIA-Grundregeln (erste ARIA-Regel: «verwende kein ARIA wenn natürliches HTML ausreicht»; native HTML-Elemente haben implizite ARIA-Rollen); ARIA-Rollen: role=«button» (wenn div/span als Button; besser: <button>); role=«dialog» (für Modale); role=«navigation»; role=«search»; role=«alert» (für Live-Regions); role=«switch» (für Toggle); ARIA-Properties: aria-label (Beschriftung für Screen-Reader); aria-labelledby (verweist auf Label-Element); aria-describedby (ergänzende Beschreibung); aria-expanded (Accordion/Dropdown-Zustand); aria-checked (Checkbox/Switch-Zustand); aria-disabled; aria-hidden (von Screen-Reader verstecken); Live-Regions: aria-live=«polite» (nach Abschluss aktueller Aktion vorlesen; für Benachrichtigungen); aria-live=«assertive» (sofort unterbrechen; nur für kritische Fehler); aria-atomic (gesamten Bereich vorlesen nicht nur Änderung); Focus-Management bei SPAs: bei Route-Wechsel Fokus explizit auf neue Seite setzen (<h1> oder Skip-Link-Ziel); ReactRouter/Next.js: keine automatische Focus-Verwaltung; manuell implementieren; Focus-Trap in Modals: wenn Modal geöffnet; Tab-Reihenfolge auf Modal begrenzen; ESC zum Schließen; Fokus-Rückkehr zum auslösenden Element beim Schließen
Gesetzliche Anforderungen und Implementierung
- Rechtliche Grundlagen in Deutschland und EU: EU Web Accessibility Directive (Richtlinie 2016/2102/EU): öffentliche Stellen; seit September 2020 (Mobile Apps seit Juni 2021); WCAG 2.1 AA als Mindeststandard; Barrierefreiheitserklärung verpflichtend; Beschwerdemechanismus vorgeschrieben; in Deutschland umgesetzt durch BITV 2.0 (Barrierefreie-Informationstechnik-Verordnung; aktualisiert 2019); European Accessibility Act (EAA; Richtlinie 2019/882; Umsetzungsfrist 28. Juni 2025): erstmals Pflicht für private Unternehmen; Produkte und Dienstleistungen im Endverbrauchermarkt; betroffen: E-Commerce; Banking; Telekommunikation; Personenverkehr; digitale Medien; Buchhaltungssoftware; in Deutschland umgesetzt durch BFSG (Barrierefreiheitsstärkungsgesetz; 16. Juli 2021; wirksam ab 28. Juni 2025); Ausnahmen: Kleinstunternehmen (<10 Mitarbeiter; <2M€ Jahresumsatz) bei unverhältnismäßiger Belastung; Konformitätsprüfung: externe Accessibility-Audits (z.B. BIK; BITV-Selbstbewertung; WCAG 2.2 AA-Konformitätserklärung; VPAT-Dokumente); ADA (Americans with Disabilities Act; USA; 1990): Title III gilt für «public accommodations»; seit DOJ-ADA Update 2022 gilt WCAG 2.1 AA als technischer Standard; Section 508 (USA; Federal Agencies; Rehabilitation Act; 2017 aktualisiert auf WCAG 2.0 AA); weltweit: AODA (Kanada; Ontario); DDA (Australien); EN 301 549 (EU-Norm; harmonisiert mit WCAG 2.1)
- Accessibility-Implementierung im Design-Prozess: Shift-Left-Accessibility: Barrierefreiheit von Anfang an einbauen nicht nachträglich; Forrester 1:10:100-Regel gilt auch für Accessibility: Behebung in Design-Phase = 1×; in Entwicklung = 10×; nach Launch = 100×; Design-Phase-Checkliste: Farbkontrast für alle Texte und UI-Elemente prüfen (Figma-Plugin: Contrast von Marc Andrew; A11y - Colour Contrast Checker); Focus-Zustände für alle interaktiven Elemente designen (nicht nur :hover; auch :focus-visible; CSS outline oder custom Focus-Ring); Touch-Target-Mindestgröße 24×24px (WCAG 2.5.8 AA; empfohlen 44×44px nach Apple HIG); Alternativtexte für alle informativen Bilder in Design-Dokumentation spezifizieren; Alt=""-Attribut für Dekorationsbilder; Entwicklungs-Phase-Checkliste: semantisches HTML bevorzugen vor ARIA; Formulare mit <label for> oder aria-label beschriften; Fehler-Messages mit aria-describedby verknüpft; Tabindex-Strategie (nur tabindex=«0» für natürliche Reihenfolge; tabindex=«-1» für programmatischen Fokus; nie positive tabindex-Werte); Skip-Link als erstes Element; automatisierter Test in CI-Pipeline (axe-core + Jest/Playwright); Pre-Launch-Accessibility-Audit: manuelle Prüfung aller kritischen Flows mit Tastatur und Screen-Reader; WCAG-Konformitätserklärung aktualisieren