Web-Barrierefreiheit & WCAG-Standards

WCAG 2.1 ist um vier Prinzipien herum organisiert, die man sich mit dem Akronym POUR merken kann. Wahrnehmbar (Perceivable): Benutzer müssen alle Informationen und UI-Komponenten über mindestens einen Sinn wahrnehmen können. Anforderungen: Alle Bilder haben beschreibenden Alt-Text; alle Videoinhalte haben Untertitel; Farbe ist nicht die einzige Art der Informationsvermittlung (z.B. verwenden Fehlerzustände zusätzlich zur roten Farbe Text oder Symbole); Text behält einen ausreichenden Farbkontrast zu seinem Hintergrund (Verhältnis 4,5:1 für normalen Text; 3:1 für großen Text bei AA-Konformität). Bedienbar (Operable): Alle Funktionen müssen ausschließlich über die Tastatur bedienbar sein (Benutzer mit motorischen Behinderungen, die keine Maus verwenden können, müssen in der Lage sein, alle Workflows mit Tab, Enter, Pfeiltasten und Escape zu navigieren, zu aktivieren und abzuschließen). Anforderungen: Fokus-Zustände sind deutlich sichtbar; keine Tastaturfallen (Benutzer kann immer aus jedem UI-Element navigieren); Sprunglinks für Screenreader-Benutzer. Verständlich (Understandable): Die Schnittstelle muss in ihrer Sprache, ihrem Verhalten und ihrer Fehlerbehandlung verständlich sein. Anforderungen: Die Sprache der Seite ist im HTML angegeben; Formularfelder haben sichtbare Beschriftungen; Fehlermeldungen identifizieren klar, was schiefgelaufen ist und wie es behoben werden kann; das UI-Verhalten ist vorhersehbar (keine unerwarteten Kontextänderungen beim Fokus). Robust (Robust): Inhalte müssen von assistierenden Technologien zuverlässig interpretiert werden können. Anforderungen: Semantisches HTML (verwenden Sie Überschriftenhierarchie, Landmark-Elemente, ARIA-Rollen angemessen); Formularelemente haben zugehörige Beschriftungen; benutzerdefinierte interaktive Komponenten implementieren das korrekte ARIA-Muster.

Barrierefreiheitstests erfordern eine Kombination aus automatisiertem Scannen und manuellem Testen – automatisierte Tools finden etwa 30–40 % der WCAG-Probleme; manuelles Testen mit assistierenden Technologien und Benutzerforschung mit Menschen mit Behinderungen findet den Rest. Automatisierte Testtools: Axe (Browser-Erweiterung + CI-Integration – das am weitesten verbreitete, genaueste automatisierte Tool); WAVE (WebAIMs Browser-Erweiterung – gut für die visuelle Anmerkung von Problemen); Lighthouse (in Chrome DevTools integriert – beinhaltet ein Barrierefreiheits-Audit). Automatisierte Tests sollten in der CI-Pipeline bei jedem Pull Request ausgeführt werden und den Build fehlschlagen lassen, wenn neue Barrierefreiheitsverletzungen eingeführt werden. Manuelles Testprotokoll: Audit der Tastaturnavigation (jeden Workflow nur mit der Tastatur navigieren – Tab zum Vorwärtsnavigieren, Shift+Tab zum Rückwärtsnavigieren, Enter/Leertaste zum Aktivieren, Escape zum Schließen). Dokumentieren Sie alle Fallen oder unterbrochenen Pfade. Screenreader-Tests: Testen Sie mit NVDA + Firefox (Windows, kostenlos) und VoiceOver + Safari (macOS, integriert). Navigieren Sie durch die zentralen Benutzerabläufe und identifizieren Sie alle Elemente, die nicht korrekt angekündigt werden, fehlenden Kontext haben oder Verwirrung stiften. Farbkontrastprüfung: Verwenden Sie ein Farbkontrastanalyse-Tool (ColorContrastChecker, Colour Contrast Analyser App) für alle Text-/Hintergrundkombinationen im Designsystem und Produkt. Benutzertests mit Menschen mit Behinderungen: Vierteljährliche Usability-Sitzungen mit 2–3 Benutzern mit relevanten Behinderungen (visuell, motorisch, kognitiv) liefern die qualitativen Erkenntnisse, die automatisierte Tools nicht generieren können.

Ein Voluntary Product Accessibility Template (VPAT) ist ein standardisiertes Dokument – veröffentlicht vom Information Technology Industry Council (ITI) –, das beschreibt, wie ein Produkt jedes WCAG 2.1-Kriterium und die Anforderungen von Section 508 (das US-amerikanische Bundesgesetz zur Barrierefreiheit) erfüllt. Beschaffungsteams von Unternehmen und Behörden verlangen einen ausgefüllten VPAT (formell als Accessibility Conformance Report, ACR, bezeichnet) als Teil der Lieferantenbewertung. Ohne einen VPAT werden viele Geschäfte im Regierungs-, Gesundheits-, Finanzdienstleistungs- und Bildungssektor automatisch disqualifiziert – das Äquivalent zum Sicherheitsfragebogen für Barrierefreiheit. VPAT-Abschnitte: Für jedes WCAG-Erfolgskriterium vermerkt der VPAT: Unterstützt (das Produkt erfüllt das Kriterium vollständig); Teilweise unterstützt (das Produkt erfüllt einige, aber nicht alle Anforderungen mit Erklärung); Nicht unterstützt (das Produkt erfüllt dieses Kriterium nicht mit Erklärung); und Nicht zutreffend (das Kriterium gilt nicht für diesen Produkttyp). VPAT-Ehrlichkeit und -Genauigkeit: Ein VPAT, der „Unterstützt“ für Kriterien beansprucht, die das Produkt nicht erfüllt, stellt eine rechtliche Haftung dar. Der VPAT sollte mit einer Kombination aus Barrierefreiheits-Auditergebnissen (automatisiertes + manuelles Testen) und rechtlicher Überprüfung erstellt werden. Product Ops koordiniert die VPAT-Erstellung – beauftragt einen externen Barrierefreiheitsberater für das Audit, das Rechtsteam für die Überprüfung und pflegt einen vierteljährlichen Aktualisierungszyklus, wenn sich das Produkt ändert (ein VPAT, der älter als 12 Monate ist und keine Updates enthält, wird von Beschaffungsteams als unzuverlässig angesehen).