Digitale Barrierefreiheit — was WCAG und der EAA von Unternehmen jetzt verlangen

Was digitale Barrierefreiheit bedeutet und wen sie betrifft

Digitale Barrierefreiheit bedeutet, dass Webseiten, Apps und digitale Dienste so gestaltet sind, dass sie von Menschen mit verschiedensten Einschränkungen vollständig genutzt werden können — Sehbehinderungen von Farbfehlsichtigkeit bis Blindheit, Hörbehinderungen, motorische Einschränkungen (etwa keine Mausnutzung möglich) und kognitive Besonderheiten wie Legasthenie oder ADHS. Weltweit lebt etwa jeder sechste Mensch mit einer Behinderung — das ist keine Randgruppe.

Die gesetzliche Grundlage in Deutschland war bisher die BITV 2.0, die nur öffentliche Stellen verpflichtete. Das ändert sich grundlegend mit dem European Accessibility Act (EAA), der als Barrierefreiheitsstärkungsgesetz (BFSG) ab dem 28. Juni 2025 für viele private Unternehmen gilt. Betroffen sind Unternehmen, die Produkte oder Dienstleistungen in der EU anbieten — Webshops, Banking-Apps, Buchungsportale, E-Reader, Geldautomaten, Telefondienste und mehr. Kleinstunternehmen mit weniger als 10 Mitarbeitenden und unter 2 Millionen Euro Jahresumsatz sind von der Pflicht ausgenommen; alle anderen sollten prüfen, ob ihr Angebot in den Geltungsbereich fällt.

WCAG 2.2: die vier Prinzipien

Die Web Content Accessibility Guidelines (WCAG) der W3C sind der technische Standard hinter nahezu allen Barrierefreiheitsanforderungen weltweit. WCAG 2.2 (verabschiedet Oktober 2023) strukturiert Anforderungen nach vier Prinzipien: wahrnehmbar (Inhalte müssen für alle Sinne zugänglich oder substituierbar sein), bedienbar (Navigation und Interaktion müssen ohne Maus funktionieren), verständlich (Inhalte und Bedienung müssen klar und vorhersagbar sein) und robust (Inhalte müssen von assistiven Technologien zuverlässig interpretiert werden können).

Jede Anforderung ist einem von drei Konformitätsniveaus zugeordnet: Level A (grundlegend), Level AA (Standard für die meisten gesetzlichen Anforderungen, auch für den EAA) und Level AAA (höchste Stufe, nur für spezialisierte Angebote sinnvoll). Konkret bedeutet Level AA unter anderem: Farbkontrast von mindestens 4,5:1 für normalen Text, vollständige Tastaturnavigation, Alt-Texte für informative Bilder, Untertitel für Videos mit Audio und korrekte Formular-Labels. WCAG 2.2 hat gegenüber 2.1 unter anderem Anforderungen an sichtbare Fokusindikatoren, Drag-and-Drop-Alternativen und Schutz vor unbeabsichtigter Authentifizierung ergänzt.

Konkrete Anforderungen für eine barrierefreie Website

• Alt-Texte: Alle informativen Bilder benötigen beschreibende Alternativtexte, dekorative Bilder ein leeres alt-Attribut.
• Tastaturnavigation: Alle interaktiven Elemente müssen per Tastatur erreichbar und bedienbar sein.
• Farbkontrast: Normaler Text braucht mindestens 4,5:1 Kontrastverhältnis, großer Text (18pt+) mindestens 3:1.
• Formulare: Jedes Eingabefeld benötigt ein zugehöriges Label-Element, Fehlermeldungen müssen klar und verständlich sein.
• Videos: Alle Videos mit gesprochenem Inhalt benötigen Untertitel, wichtige Inhalte zusätzlich eine Audiodeskription.
• ARIA-Attribute: Dynamische Inhalte und Custom-Components brauchen korrekte ARIA-Rollen und -Eigenschaften für Screenreader.
• Fokusindikatoren: Der Tastaturfokus muss jederzeit sichtbar sein — kein outline: none ohne Alternative.
• Sprachauszeichnung: Das lang-Attribut im HTML muss die Seitensprache korrekt ausweisen.

Wie man korrekt prüft

Automatische Tools können etwa 30–40 % der WCAG-Anforderungen prüfen. Zu den bewährtesten gehören axe (Browser-Extension), WAVE (kostenlos online), Google Lighthouse (integriert in Chrome DevTools) und die kostenpflichtige Enterprise-Lösung Siteimprove. Diese Tools finden fehlende Alt-Texte, Kontrastprobleme, fehlende Formular-Labels und ungültige ARIA-Attribute zuverlässig.

Was automatische Tools nicht prüfen können: ob ein Alt-Text inhaltlich sinnvoll ist, ob die Tastaturnavigation logisch ist, ob Formulare verständlich sind, und ob ein Screenreader-Nutzer die Seite tatsächlich bedienen kann. Dafür braucht es manuelle Tests, idealerweise mit echten Screenreader-Nutzern oder zumindest mit Werkzeugen wie NVDA, VoiceOver oder TalkBack.

Nach der Prüfung ist eine Barrierefreiheitserklärung Pflicht: Sie dokumentiert den angestrebten WCAG-Standard, bekannte Einschränkungen und wie Nutzer Probleme melden können. Die Erklärung muss auf der Website verlinkt und zugänglich sein, üblicherweise im Footer neben Impressum und Datenschutz.

Barrierefreiheit schrittweise umsetzen

1. Bestandsaufnahme mit automatischen Tools: Ein Scan mit axe oder WAVE liefert einen Überblick über die häufigsten technischen Probleme und deren Häufigkeit. 2. Priorisierung nach Schwere und Häufigkeit: Fehlende Alt-Texte auf dem Startseiten-Headerbild wiegen schwerer als ein Kontrastproblem im Footer. 3. Manuelle Tastaturnavigation testen: Die gesamte Website ausschließlich per Tab, Shift+Tab, Enter und Pfeiltasten durchgehen — sind alle Funktionen erreichbar, ist der Fokus jederzeit sichtbar? 4. Barrierefreiheitserklärung erstellen: mit Konformitätsstatus, bekannten Mängeln, Kontaktmöglichkeit und Feedback-Mechanismus. 5. Regelmäßige Nachprüfung einplanen: Barrierefreiheit ist kein einmaliges Projekt — jede neue Funktion, jeder neue Inhalt muss die Standards einhalten.

Barrierefreiheitserklärungen, die lediglich „vollständig konform" behaupten, ohne dies durch Tests belegen zu können, sind problematisch — Abmahnvereine und Behindertenverbände können seit dem BFSG aktiv klagen. Transparenz über bekannte Mängel und ein Kontaktweg schützen besser als eine falsche Konformitätsbehauptung. Barrierefreiheit und SEO überschneiden sich zudem erheblich: saubere Überschriftenstruktur, Alt-Texte, schnelle Ladezeiten und verständliche Texte verbessern beides gleichzeitig.