Warum WCAG 2.2 AA jetzt Pflicht ist
Seit dem 28. Juni 2025 verpflichtet das BFSG Unternehmen, ihre digitalen Angebote barrierefrei zu gestalten. Der technische Maßstab ist die europäische Norm EN 301 549, die auf den Web Content Accessibility Guidelines (WCAG) 2.2 in Konformitätsstufe AA aufbaut. Für Firmenwebsites bedeutet das: Wer Produkte oder Dienstleistungen an Verbraucher verkauft, muss die Vorgaben einhalten. Bei Verstößen drohen Bußgelder von bis zu 100.000 EUR (BFSG). Gleichzeitig zeigt die Praxis, dass rund vier von fünf der getesteten deutschen Online-Shops noch nicht barrierefrei sind (Aktion Mensch). Die Übergangsfrist ist abgelaufen — ab sofort können Marktüberwachungsbehörden Verstöße ahnden und Wettbewerber kostenpflichtige Abmahnungen aussprechen.
Die wirtschaftliche Dimension ist dabei mindestens ebenso relevant wie die rechtliche: Barrierefreie Websites erzielen typischerweise eine 19,3 % höhere Conversion-Rate (Global Conversion Study). Der globale Disability-Markt umfasst rund 13 Billionen USD Kaufkraft (World Economic Forum). Barrierefreiheit ist also kein reines Compliance-Thema, sondern ein Umsatzfaktor — und ein SEO-Vorteil, den Suchmaschinen zunehmend honorieren.
Neben dem Bußgeld bis 100.000 EUR können Wettbewerber und Verbraucherschutzverbände Unterlassungsansprüche geltend machen. Eine frühzeitige WCAG-Prüfung minimiert das Abmahnrisiko erheblich.
Fehler 1: Unzureichende Farbkontraste
Farbkontraste sind mit Abstand das häufigste WCAG-Problem: 83,9 % aller geprüften Websites weisen Kontrastfehler auf (WebAIM Million 2026). Das WCAG-Kriterium 1.4.3 fordert ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text (ab 18pt oder 14pt fett). In der Praxis scheitern besonders häufig hellgraue Texte auf weißem Grund, farbige Buttons mit weißer Schrift und Platzhaltertexte in Formularen.
Die Lösung beginnt im Design-System: Definieren Sie Farbpaare, die das geforderte Kontrastverhältnis einhalten, und verankern Sie diese als CSS-Custom-Properties. So verhindern Sie, dass Einzelentscheidungen im Entwicklungsprozess den Standard unterlaufen. Der BFSG-Barrierefreiheitscheck von XICTRAQ erkennt Kontrastverstöße automatisiert und dokumentiert sie mit dem exakten Verhältniswert.
Besonders tückisch sind Kontraste in interaktiven Zuständen: Hover-Farben, Fokus-Indikatoren und deaktivierte Buttons werden bei der Prüfung häufig übersehen. WCAG 2.2 verschärft die Anforderungen mit dem neuen Kriterium 2.4.13 (Focus Appearance), das einen sichtbaren Fokusindikator mit ausreichendem Kontrast fordert. Für Firmenwebsites bedeutet das: Nicht nur der Standardzustand muss geprüft werden, sondern jeder interaktive Zustand eines Elements.
Fehler 2: Fehlende Alt-Texte bei Bildern
Bilder ohne Alt-Texte sind für Screenreader-Nutzer unsichtbar. 53,1 % der untersuchten Websites haben mindestens ein Bild ohne alternatives Textattribut (WebAIM Million 2026). Das betrifft sowohl informative Bilder, die eine Beschreibung benötigen, als auch dekorative Bilder, die ein leeres alt="" erhalten sollten, damit Screenreader sie überspringen.
Ein häufiger Fehler ist auch die Verwendung nichtssagender Alt-Texte wie "Bild" oder "IMG_2847.jpg". Gute Alt-Texte beschreiben, was das Bild zeigt und warum es im Kontext relevant ist. Für E-Commerce-Seiten bedeutet das: Produktbilder benötigen Beschreibungen mit Produktname, Farbe und wesentlichen Merkmalen — nicht nur den Dateinamen.
Für Content-Management-Systeme empfiehlt sich ein Pflichtfeld für Alt-Texte im Upload-Dialog. So werden fehlende Beschreibungen bereits bei der Erstellung verhindert, statt sie nachträglich ergänzen zu müssen. Regelmäßige automatisierte Scans decken dennoch Lücken auf — etwa bei nachträglich eingebundenen Bildern, SVG-Grafiken ohne <title>-Element oder <input type="image">-Elementen ohne Alt-Text.
Fehler 3: Fehlende Formular-Labels
51 % der Websites haben Formularfelder ohne programmatisch verknüpfte Labels (WebAIM Million 2026). Ein visuell sichtbarer Text neben dem Eingabefeld reicht nicht aus — das <label>-Element muss über das for-Attribut mit der id des Eingabefelds verbunden sein. Alternativ kann das Eingabefeld innerhalb des <label> stehen.
Besonders kritisch sind Login-Formulare und Checkout-Prozesse: Wenn ein Screenreader-Nutzer nicht erkennen kann, welches Feld für E-Mail und welches für das Passwort vorgesehen ist, bricht der Prozess ab. Das Login-Flow-Monitoring hilft dabei, solche Abbrüche zu erkennen und auf strukturelle Probleme zurückzuführen.
Ein einfacher Test: Klicken Sie auf den Labeltext eines Formularfelds. Springt der Cursor in das zugehörige Eingabefeld, ist die Verknüpfung korrekt. Springt er nicht, fehlt die programmatische Verbindung. Für komplexere Formulare mit Checkbox-Gruppen und Radio-Buttons sind zusätzlich <fieldset> und <legend> erforderlich, um die Gruppenzugehörigkeit für Screenreader verständlich zu machen.
Fehler 4: Leere Links ohne Beschreibung
46,3 % der Websites enthalten Links ohne erkennbaren Text (WebAIM Million 2026). Typische Auslöser sind Icon-Links ohne aria-label, Bilder in Links ohne Alt-Text und Links, deren sichtbarer Text nur aus Leerzeichen besteht. Für Screenreader-Nutzer sind solche Links nicht identifizierbar — sie hören nur "Link" ohne weitere Information.
Die Behebung ist meist einfach: Ergänzen Sie ein aria-label mit beschreibendem Text oder fügen Sie einen visuell versteckten <span class="sr-only"> ein. Bei Social-Media-Icons genügt beispielsweise aria-label="Zu unserem LinkedIn-Profil". Wichtig: Der Linktext sollte das Ziel beschreiben, nicht die Aktion — also "Produktdetails" statt "Hier klicken". Achten Sie auch auf sogenannte Mehrdeutigkeiten: Wenn mehrere Links auf einer Seite den gleichen Text tragen (etwa mehrfach "Mehr erfahren"), kann ein Screenreader-Nutzer nicht unterscheiden, welcher Link wohin führt. Kontextabhängige oder einzigartige Linktexte lösen dieses Problem.
Fehler 5: Leere Buttons ohne Text
30,6 % der Websites haben Buttons ohne zugänglichen Namen (WebAIM Million 2026). Das Problem ähnelt den leeren Links: Icon-Buttons wie Hamburger-Menüs, Schließen-Kreuze oder Suchlupen haben kein Textäquivalent. Screenreader geben dann nur "Button" aus, ohne den Zweck zu vermitteln.
Die Lösung: Jeder <button> benötigt entweder sichtbaren Text, ein aria-label oder einen <span class="sr-only"> mit beschreibendem Inhalt. Für das Hamburger-Menü wäre das aria-label="Hauptmenü öffnen", für das Schließen-Kreuz aria-label="Dialog schließen". Testen Sie die Benennung, indem Sie sich vorstellen, Sie müssten die Seite jemandem am Telefon beschreiben.
Fehler 6: Fehlerhafte ARIA-Attribute
ARIA (Accessible Rich Internet Applications) soll Screenreadern zusätzlichen Kontext liefern. Doch auf 82,7 % der Websites, die ARIA verwenden, sind die Attribute fehlerhaft implementiert (WebAIM Million 2026). Häufige Fehler: aria-labelledby verweist auf eine nicht existierende ID, role-Attribute widersprechen dem nativen HTML-Element, oder aria-hidden="true" verbirgt interaktive Elemente vor assistiven Technologien.
Wenn ein natives HTML-Element die gewünschte Semantik bietet, verwenden Sie es statt ARIA. Ein <button> ist einem <div role="button"> immer vorzuziehen. ARIA ist ein Notbehelf, keine Verbesserung von gutem HTML.
Ein verbreiteter Anti-Pattern ist das sogenannte "ARIA-Soup": Entwickler fügen Dutzende ARIA-Attribute hinzu, um Barrierefreiheit zu signalisieren, ohne deren Wirkung zu verstehen. Das Ergebnis ist häufig schlechter als ganz ohne ARIA. Validieren Sie ARIA-Verwendung mit dem HTTP-Security-Headers-Check kombiniert mit einem Accessibility-Audit, um sowohl technische Sicherheit als auch korrekte Semantik sicherzustellen.
Fehler 7: Fehlende Skip-Navigation
Nur 17,1 % der Websites bieten einen Skip-Navigation-Link an (WebAIM Million 2026). Skip-Links ermöglichen Tastaturnutzern, die Hauptnavigation zu überspringen und direkt zum Seiteninhalt zu springen. Ohne diesen Mechanismus muss ein Tastaturnutzer auf jeder Seite alle Navigationslinks per Tab durchlaufen, bevor er den eigentlichen Inhalt erreicht.
Die Implementierung ist unkompliziert: Ein Link am Seitenanfang mit href="#main-content" und einem entsprechenden id="main-content" auf dem <main>-Element. Der Link kann visuell verborgen sein und erst beim Fokus per Tastatur sichtbar werden. Diese wenigen Zeilen Code haben einen erheblichen Einfluss auf die Nutzbarkeit für Tastaturnutzer. Ergänzend sollten Landmark-Rollen (<nav>, <main>, <aside>, <footer>) korrekt eingesetzt werden, da Screenreader-Nutzer auch über diese navigieren können.
Fehler 8: Fehlende Sprach-Deklaration
Das lang-Attribut im <html>-Tag teilt Screenreadern mit, in welcher Sprache der Seiteninhalt verfasst ist. Ohne diese Deklaration raten Screenreader die Sprache — mit oft unverständlichen Ergebnissen, wenn ein englischer Screenreader deutschen Text mit englischer Aussprache vorliest. Für mehrsprachige Websites müssen zusätzlich Textabschnitte in Fremdsprachen mit lang-Attributen gekennzeichnet werden.
Für eine deutsche Website genügt <html lang="de">. Bei englischen Zitaten oder Fachbegriffen ergänzen Sie <span lang="en">Content Security Policy</span>. Diese einfache Maßnahme verbessert nicht nur die Barrierefreiheit, sondern auch die automatische Übersetzung und die SEO-Bewertung durch Suchmaschinen.
Fehler 9: Fehlende Heading-Hierarchie
Screenreader-Nutzer navigieren Websites häufig über die Überschriftenstruktur. Eine logische Hierarchie — eine <h1> pro Seite, darunter <h2>, <h3> ohne übersprungene Ebenen — ist entscheidend für die Orientierung. In der Praxis verwenden viele Websites Headings rein aus stilistischen Gründen: Ein <h4> wird gewählt, weil die Schriftgröße passt, nicht weil die semantische Ebene stimmt.
Trennen Sie Semantik und Styling konsequent: Verwenden Sie Headings für die inhaltliche Struktur und CSS-Klassen für die visuelle Gestaltung. Ein Lighthouse-Audit deckt Hierarchie-Probleme zuverlässig auf und zeigt, wo Headings übersprungen oder falsch eingesetzt werden.
Fehler 10: Fehlende Tastatur-Bedienbarkeit
Jedes interaktive Element einer Website muss per Tastatur erreichbar und bedienbar sein. In der Praxis scheitern daran vor allem Custom-Widgets: Dropdown-Menüs, die nur auf Hover reagieren, modale Dialoge ohne Fokus-Management und Slider ohne Tastatursteuerung. Auch div- und span-Elemente mit Click-Handlern, die nicht per Tab fokussierbar sind, schließen Tastaturnutzer aus.
Die Lösung: Verwenden Sie native HTML-Elemente wie <button>, <a> und <select>, die bereits Tastatur-Support mitbringen. Wo Custom-Widgets nötig sind, implementieren Sie die WAI-ARIA Authoring Practices: Tab- und Pfeiltasten-Navigation, Escape zum Schließen, Fokus-Trap in modalen Dialogen. Testen Sie jede Seite einmal vollständig per Tastatur — ohne Maus.
Eine systematische Tastatur-Prüfung folgt einem festen Protokoll: Tab durch die gesamte Seite, überprüfen ob jedes interaktive Element erreichbar ist, Enter/Space für Aktivierung testen, Escape für das Schließen von Dialogen prüfen und die Pfeiltasten-Navigation in Menüs und Tabs verifizieren. Dokumentieren Sie jede Stelle, an der der Fokus verloren geht oder ein Element nicht erreichbar ist. Diese manuelle Prüfung ergänzt die automatisierten Tests des BFSG-Barrierefreiheitschecks um die Aspekte, die kein Scanner erkennen kann.
96 % aller Fehler in sechs Kategorien
Die WebAIM Million 2026 Studie zeigt ein klares Muster: 96 % aller automatisiert erkennbaren Fehler fallen in nur sechs Kategorien (WebAIM Million 2026). Das sind die ersten sechs Fehler dieser Liste — Kontrast, Alt-Texte, Labels, leere Links, leere Buttons und fehlerhafte ARIA-Attribute. Diese Konzentration ist gleichzeitig Problem und Chance: Wer diese sechs Bereiche systematisch abarbeitet, beseitigt den Großteil der messbaren Barrieren.
Der effizienteste Ansatz ist dabei die seitenübergreifende Analyse: Statt jede Seite einzeln zu prüfen, identifizieren Sie zuerst die Templates und Komponenten, die auf vielen Seiten wiederverwendet werden. Ein Kontrastfehler im Header-Template betrifft jede Seite der Website. Ein fehlendes Label im Newsletter-Formular, das im Footer eingebunden ist, multipliziert sich über Hunderte von Seiten. Durch die Korrektur an der Komponente statt an der Einzelseite sinkt die Fehleranzahl typischerweise drastisch mit minimalem Aufwand.
| Fehler-Kategorie | Anteil betroffener Websites | WCAG-Kriterium |
|---|---|---|
| Farbkontraste | 83,9 % (WebAIM Million 2026) | 1.4.3 Contrast |
| Alt-Texte | 53,1 % (WebAIM Million 2026) | 1.1.1 Non-text Content |
| Formular-Labels | 51,0 % (WebAIM Million 2026) | 1.3.1 Info and Relationships |
| Leere Links | 46,3 % (WebAIM Million 2026) | 2.4.4 Link Purpose |
| Leere Buttons | 30,6 % (WebAIM Million 2026) | 4.1.2 Name, Role, Value |
| ARIA-Fehler | 82,7 % fehlerhaft (WebAIM Million 2026) | 4.1.2 Name, Role, Value |
WCAG-Fehler systematisch erkennen und beheben
Automatisierte Tests sind der erste Schritt, ersetzen aber keine manuelle Prüfung. Tools wie der XICTRAQ Barrierefreiheitscheck erkennen rund 30-40 % der WCAG-Kriterien automatisiert — darunter alle sechs Hauptkategorien aus der WebAIM-Studie. Für die verbleibenden Kriterien, etwa die Verständlichkeit von Inhalten oder die Logik der Tab-Reihenfolge, ist manuelles Testing erforderlich.
- Automatisierten Scan ausführen — Alle Seiten auf die sechs Hauptkategorien prüfen und Fehler nach Schweregrad priorisieren
- Template-basiert korrigieren — Wiederverwendete Komponenten zuerst beheben, da ein Fix Hunderte Seiten gleichzeitig verbessert
- Manuell testen — Tastatur-Navigation, Screenreader-Kompatibilität und Fokus-Management an kritischen Stellen prüfen
- Regressionstests einrichten — Accessibility-Check in den Deployment-Prozess integrieren, um neue Fehler frühzeitig zu erkennen
- Dokumentieren — Prüfprotokolle und Fortschrittsnachweise für die BFSG-Nachweispflicht aufbewahren
Regelmäßige Prüfung aller Seiten auf WCAG 2.2 AA-Verstöße mit Priorisierung nach Schweregrad und betroffener Seitenzahl.
Dokumentation der Entwicklung über Zeit: Wie viele Fehler wurden behoben, wo bestehen Regressionen?
Automatische Benachrichtigung, wenn ein Deployment neue Barrierefreiheits-Fehler einführt.
Exportierbare Reports für die Dokumentationspflicht nach BFSG — mit Zeitstempel und Prüfergebnis.
Ein bewährter Workflow: Starten Sie mit dem automatisierten Scan, priorisieren Sie nach Schweregrad (Kontrast und Labels zuerst), implementieren Sie die Korrekturen und prüfen Sie erneut. Integrieren Sie den Accessibility-Check in Ihren Deployment-Prozess, damit neue Fehler sofort auffallen. Die Kombination mit Content Security Policy (CSP) und SSL-Monitoring ergibt ein umfassendes Sicherheits- und Compliance-Paket.
Barrierefreiheit als Conversion-Faktor
Barrierefreiheit verbessert nicht nur die Nutzbarkeit für Menschen mit Behinderungen, sondern für alle Nutzer. Klare Kontraste, verständliche Labels und eine logische Seitenstruktur senken die kognitive Last und vereinfachen die Navigation. Studien belegen, dass barrierefreie Websites typischerweise eine 19,3 % höhere Conversion-Rate erzielen (Global Conversion Study).
Der globale Disability-Markt repräsentiert eine Kaufkraft von rund 13 Billionen USD (World Economic Forum). Wer diese Zielgruppe durch Barrieren ausschließt, verzichtet auf erhebliches Umsatzpotenzial. Dabei gehen die Vorteile über die direkt betroffenen Nutzer hinaus: Ältere Menschen, Nutzer mit temporären Einschränkungen (gebrochener Arm, helles Sonnenlicht auf dem Display) und Mobile-Nutzer profitieren gleichermaßen. Gerade im E-Commerce-Bereich wirkt sich eine barrierefreie Produktseite direkt auf die Kaufentscheidung aus: Klare Beschriftungen, ausreichende Touch-Ziele und verständliche Fehlermeldungen reduzieren Kaufabbrüche messbar.
Barrierefreie Websites erzielen typischerweise höhere Conversions, bessere SEO-Rankings und einen größeren adressierbaren Markt. Die Investition in WCAG-Konformität zahlt sich in der Regel über messbar verbesserte Kennzahlen zurück.
Prüfen, beheben, dauerhaft überwachen
WCAG-Konformität ist kein einmaliges Projekt, sondern ein fortlaufender Prozess. Jedes CMS-Update, jedes neue Plugin und jede Design-Änderung kann neue Barrieren einführen. Ohne kontinuierliche Überwachung entdecken Sie Regressionen erst bei der nächsten manuellen Prüfung — oder durch eine Abmahnung.
XICTRAQ verbindet den Barrierefreiheitscheck mit Uptime-Monitoring, Security-Scans und DSGVO-Compliance in einer Plattform. So erhalten Sie ein vollständiges Bild der technischen Qualität Ihrer Website und können Probleme beheben, bevor sie Nutzer oder Behörden betreffen. Starten Sie mit einer kostenlosen Testphase oder verschaffen Sie sich einen Überblick in der Live-Demo.
Dieser Artikel basiert auf Daten von: WebAIM Million 2026 (1), Aktion Mensch (aktion-mensch.de), BFSG — Barrierefreiheitsstärkungsgesetz, Global Conversion Study, World Economic Forum (weforum.org).