Kaum ein Kürzel taucht in Ausschreibungen, Gesetzestexten und Audit-Berichten so oft auf wie WCAG – und kaum eines wird so oft missverstanden. Viele Entscheider hören „technischer Standard“ und schalten innerlich ab. Das ist ein Fehler, denn hinter den WCAG steht eine erstaunlich klare Logik, an der heute Ihre Rechtssicherheit, Ihre Reichweite und Ihre Conversion hängen. Ich erkläre Ihnen, wie die Richtlinien aufgebaut sind, welche Stufe für Sie verbindlich ist, was WCAG 2.2 Neues bringt – und ich zeige Ihnen anhand aktueller Daten die sechs Fehler, die fast alle Verstöße ausmachen. Mit konkreten Erfolgskriterien, echten Audit-Beispielen und einem Werkzeug, das Sie sofort anwenden können.
Was sind die WCAG?
Die WCAG (Web Content Accessibility Guidelines) sind der internationale Standard für barrierefreie Webinhalte, herausgegeben vom World Wide Web Consortium (W3C). Sie übersetzen das abstrakte Ziel „digitale Teilhabe für alle“ in konkrete, prüfbare Erfolgskriterien – also messbare Anforderungen dafür, wie eine Website oder App gestaltet sein muss. Die WCAG sind die Grundlage, auf der nahezu alle nationalen Gesetze zur Barrierefreiheit aufbauen, vom deutschen BFSG bis zur EU-Norm EN 301 549.
Der Aufbau folgt einer klaren Hierarchie, die Sie kennen sollten, weil sie die ganze Logik trägt: An oberster Stelle stehen vier Prinzipien. Darunter ordnen sich Richtlinien, die jeweils durch testbare Erfolgskriterien präzisiert werden – jedes mit einer eindeutigen Nummer wie 1.4.3 oder 2.4.7. Ergänzend liefert das W3C technikspezifische Methoden, wie ein Kriterium praktisch zu erfüllen ist. Der entscheidende Unterschied zu vagen Empfehlungen: Jedes Erfolgskriterium lässt sich mit Ja oder Nein beantworten. Entweder ein Bild hat eine sinnvolle Textalternative oder nicht. Diese Prüfbarkeit macht die WCAG zum belastbaren Maßstab – und genau deshalb beziehen sich Behörden und Gerichte auf sie.
Die vier Prinzipien der WCAG
Alle Erfolgskriterien ordnen sich vier Grundprinzipien unter, oft mit dem englischen Akronym POUR zusammengefasst: wahrnehmbar, bedienbar, verständlich und robust. Diese vier Prinzipien sind kein theoretisches Gerüst, sondern ein Prüfraster: Jedes lässt sich in eine konkrete Frage übersetzen – Ist der Inhalt wahrnehmbar, ist er bedienbar, ist er verständlich, und ist er robust genug, um in unterschiedlichen Browsern und Hilfsmitteln gleichermaßen zu funktionieren? Wer ein Angebot entlang dieser vier Fragen durchgeht, deckt die allermeisten Barrieren systematisch auf.
Wahrnehmbar
Informationen müssen für jeden Nutzer wahrnehmbar sein – unabhängig vom genutzten Sinn. Dazu gehören Textalternativen für Bilder (Kriterium 1.1.1), Untertitel für Videos und ein ausreichender Farbkontrast (1.4.3). Wer Inhalte allein über Farbe transportiert, scheitert hier.
Bedienbar
Jede Funktion muss sich auch ohne Maus bedienen lassen – allein über die Tastatur (2.1.1). Das betrifft Menüs, Formulare und vor allem den Bezahlprozess. Hinzu kommen ein sichtbarer Tastaturfokus (2.4.7), genügend Zeit und der Verzicht auf blitzende Inhalte, die Anfälle auslösen können.
Verständlich
Inhalte und Bedienung müssen verständlich und vorhersehbar sein. Dazu zählen eine korrekt ausgezeichnete Seitensprache (3.1.1), konsistente Navigation und – besonders praxisrelevant – klare Beschriftungen und hilfreiche Fehlermeldungen in Formularen (3.3.2). Eine Fehlermeldung, die nur „ungültige Eingabe“ sagt, hilft niemandem.
Robust
Inhalte müssen robust genug sein, damit unterschiedliche Browser und Hilfsmittel sie korrekt interpretieren. Hier geht es um sauberes, semantisches HTML und darum, dass jedes Bedienelement seinen Namen, seine Rolle und seinen Zustand an einen Screenreader weitergibt (4.1.2). Robustheit ist die unsichtbare Grundlage, auf der die anderen drei Prinzipien überhaupt erst funktionieren.
Die WCAG-Konformitätsstufen A, AA und AAA
Die WCAG kennen drei Konformitätsstufen, die aufeinander aufbauen. Welche für Sie gilt, ist keine Geschmacksfrage, sondern für die Privatwirtschaft klar vorgegeben.
| Stufe | Bedeutung | Relevanz für Unternehmen |
|---|---|---|
| A | Grundlegendste Anforderungen, ohne die ein Angebot für viele Menschen unbenutzbar wäre | Notwendig, aber nicht ausreichend |
| AA | Baut auf A auf, deckt die praxisrelevanten Barrieren ab | Der verbindliche Maßstab für BFSG und EAA |
| AAA | Höchste Stufe, für manche Inhaltstypen nicht vollständig erreichbar | Freiwillige Ambition für kritische Inhalte |
Für Sie als Unternehmen ist die Antwort damit eindeutig: Stufe AA ist der relevante Maßstab. Sowohl das Barrierefreiheitsstärkungsgesetz als auch der European Accessibility Act fordern faktisch WCAG-Konformität auf dieser Stufe. AAA dürfen Sie anstreben, aber niemand verlangt von Ihnen, jede AAA-Hürde zu nehmen. Wie sich die Stufen im Detail unterscheiden, habe ich im Beitrag zu den WCAG-Konformitätsstufen aufgeschlüsselt.
Ein Tipp, der selten ausgesprochen wird: Nutzen Sie AAA wie einen Steinbruch. Einige AAA-Kriterien sind mit wenig Aufwand erreichbar und bringen spürbaren Mehrwert – etwa der erhöhte Textkontrast von 7:1 (1.4.6), Linktexte, die schon aus sich heraus verständlich sind (2.4.9), oder das Vermeiden harter Zeitbegrenzungen (2.2.6). Sie müssen die Stufe AAA nicht vollständig erfüllen; gezielt einzelne Kriterien herauszupicken hebt Ihre Qualität spürbar über das gesetzliche Pflichtminimum, ohne den Aufwand einer vollen AAA-Konformität.
Die sechs Fehler, die 96 Prozent aller WCAG-Verstöße ausmachen
Hier kommt das vielleicht nützlichste Wissen dieses Artikels. Die jährliche WebAIM-Million-Analyse durchsucht die eine Million meistbesuchten Startseiten automatisiert auf Barrierefreiheitsfehler. Das Ergebnis 2026 ist ernüchternd – und zugleich eine Steilvorlage: 95,9 Prozent der Seiten weisen erkennbare WCAG-Verstöße auf, im Schnitt 56 pro Seite. Die gute Nachricht steckt im Detail: 96 Prozent aller Fehler fallen in nur sechs Kategorien, und das seit sieben Jahren unverändert. Wer diese sechs angeht, hebt seine Barrierefreiheit dramatisch.
| Fehler | Betroffene Seiten | WCAG-Kriterium | Was es für Nutzer bedeutet |
|---|---|---|---|
| Niedriger Textkontrast | 83,9 % | 1.4.3 | Text wird für sehbehinderte Menschen unlesbar |
| Fehlende Alt-Texte | ~55 % | 1.1.1 | Bildinhalte verschwinden für Screenreader vollständig |
| Leere Links | steigend | 2.4.4 / 4.1.2 | Nutzer hören „Link“, aber kein Ziel |
| Fehlende Formular-Labels | steigend | 1.3.1 / 3.3.2 | Eingabefelder bleiben unbeschriftet und unbedienbar |
| Leere Buttons | steigend | 4.1.2 | Schaltflächen ohne angesagten Zweck |
| Fehlende Sprachauszeichnung | sinkend | 3.1.1 | Der Screenreader liest in falscher Aussprache vor |
Der häufigste Verstoß verdient eine genauere Betrachtung, weil er so vermeidbar ist. Niedriger Kontrast verletzt Erfolgskriterium 1.4.3, das für normalen Text ein Verhältnis von 4,5 zu 1 verlangt und für großen Text ab 18 Punkt (oder 14 Punkt fett) 3 zu 1. Die durchschnittliche Startseite hatte 2026 ganze 34 verschiedene Kontrastverstöße. Der Grund liegt selten im Code, sondern im Designprozess: Wenn Farbe und Schriftgröße erst einmal festgelegt sind, ist die Korrektur teuer. Kontrast ist eine Entscheidung, die im Design-Briefing fällt, nicht im Stylesheet.
Wie zwei dieser Fehler im Code aussehen
Damit die Statistik greifbar wird: Hier die zwei häufigsten unsichtbaren Fehler und wie trivial ihre Behebung ist. Ein Eingabefeld ohne verknüpftes Label meldet ein Screenreader nur als „Eingabefeld“, ohne zu sagen, was hineingehört.
<!-- Für Hilfsmittel namenlos -->
<input type="email" placeholder="E-Mail">
<!-- Label korrekt verknüpft -->
<label for="email">E-Mail-Adresse</label>
<input type="email" id="email">Der häufige Irrtum dabei: Ein placeholder ersetzt kein Label. Er verschwindet beim Tippen, hat meist zu wenig Kontrast und wird von vielen Hilfsmitteln nicht als Feldname vorgelesen. Dasselbe Prinzip gilt für leere Buttons und Links: Ein Button, der nur ein Icon ohne Textalternative enthält, wird als „Schaltfläche“ ohne Zweck angesagt – ein aria-label oder ein visuell verstecktes Textelement löst das in einer Zeile. Diese Fehler kosten in der Behebung fast nichts, summieren sich aber dramatisch, weil sie in Komponenten stecken, die hundertfach auf einer Seite wiederkehren. Genau deshalb stehen sie seit Jahren an der Spitze der Statistik.
Daraus folgt der wirkungsvollste erste Schritt überhaupt, den viele übersehen: Beheben Sie diese sechs Fehlertypen nicht mühsam Seite für Seite, sondern an der Wurzel – im Design-System und in den wiederverwendeten Bausteinen. Ein einziger korrekt gelabelter Formular-Baustein, ein zentral abgedunkelter Kontrastwert, ein sauberes Button-Pattern wirken auf hunderte Seiten gleichzeitig. Wer zentral ansetzt, eliminiert mit überschaubarem Aufwand den Löwenanteil aller Verstöße, statt dieselbe Korrektur tausendfach nachzuziehen.
Das ARIA-Paradox: Warum mehr oft weniger ist
Eine Erkenntnis aus denselben Daten überrascht selbst erfahrene Teams: Seiten, die ARIA-Attribute einsetzen, weisen im Schnitt spürbar mehr Fehler auf als Seiten ohne ARIA – 59,1 gegenüber 42. Das liegt nicht daran, dass ARIA schädlich wäre, sondern daran, dass es falsch eingesetzt wird. ARIA überschreibt die native Bedeutung von HTML-Elementen, und jeder Fehler dabei erzeugt eine neue Barriere.
WebAIM führt den Anstieg der Fehler 2026 unter anderem auf zunehmend komplexe Seiten und auf KI-gestütztes Programmieren zurück, das ARIA großzügig, aber unsauber verteilt. Daraus folgt eine Regel, die ich in jedem Projekt predige: Keine ARIA ist besser als schlechte ARIA. Ein natives <button> bringt Rolle, Zustand und Tastaturbedienung von Haus aus mit – ein <div> mit aufgesetzten ARIA-Rollen müssen Sie mühsam und fehleranfällig nachbauen. Mehr dazu im Beitrag zu ARIA und semantischem HTML.
WCAG 2.0, 2.1, 2.2 – und was es mit WCAG 3.0 auf sich hat
Die aktuelle und verbindliche Version ist WCAG 2.2, im Oktober 2023 als offizielle W3C-Empfehlung veröffentlicht. Sie erweitert die Vorgänger 2.0 (2008) und 2.1 (2018) um neun zusätzliche Erfolgskriterien und ist abwärtskompatibel: Wer WCAG 2.2 erfüllt, erfüllt automatisch auch 2.1 und 2.0. Ein einziges Kriterium der Vorversion – 4.1.1 zum Parsing – wurde gestrichen, weil moderne Browser es obsolet gemacht haben.
Die neuen Kriterien adressieren konkrete Probleme der heutigen Weboberflächen. Drei davon sollten Sie kennen, weil sie häufig übersehen werden:
- Zielgröße (2.5.8, AA): Klickflächen müssen mindestens 24 mal 24 CSS-Pixel groß sein – ein direkter Schlag gegen winzige Touch-Ziele auf Mobilgeräten.
- Zugängliche Authentifizierung (3.3.8, AA): Ein Anmeldeprozess darf nicht allein an einem Gedächtnis- oder Wahrnehmungstest hängen. Captchas ohne Alternative und kopfrechenartige Hürden fallen damit durch.
- Fokus nicht verdeckt (2.4.11, AA): Das gerade fokussierte Element darf nicht von Cookie-Bannern oder klebrigen Kopfzeilen verdeckt werden – ein verbreiteter Bug, den kaum jemand testet.
- Ziehbewegungen (2.5.7, AA): Funktionen, die eine Ziehbewegung verlangen – etwa Schieberegler oder Drag-and-drop –, müssen alternativ mit einfachem Tippen bedienbar sein. Wichtig für Menschen mit motorischen Einschränkungen.
- Redundante Eingabe (3.3.7, A): Informationen, die im selben Prozess schon erfasst wurden, dürfen nicht erneut manuell abgefragt werden – ein direkter Hebel gegen abgebrochene mehrstufige Formulare.
Diese fünf Beispiele zeigen die Stoßrichtung von WCAG 2.2: Es geht um die alltäglichen Reibungspunkte moderner Oberflächen – Mobilbedienung, mehrstufige Prozesse, überladene Layouts –, nicht um exotische Sonderfälle. Genau deshalb betreffen die neuen Kriterien fast jede Website, die seit 2018 nicht grundlegend überarbeitet wurde.
Über WCAG 3.0 kursieren viele Halbwahrheiten. Die Fakten: Der jüngste Arbeitsentwurf (Working Draft) wurde im März 2026 veröffentlicht und führt rund 174 sogenannte Outcomes ein – die Nachfolger der heutigen Erfolgskriterien. WCAG 3.0 löst dabei das starre Bestanden/Durchgefallen-Schema der Stufen A, AA und AAA durch ein abgestuftes Bewertungsmodell mit den Niveaus Bronze, Silber und Gold ab, das Barrierefreiheit als Spektrum statt als reines Häkchen begreift. Bis zur offiziellen W3C-Empfehlung ist es allerdings weit: Eine Candidate Recommendation wird frühestens für Ende 2027 erwartet, die finale Empfehlung nicht vor 2028 – realistisch eher gegen Ende des Jahrzehnts. Und WCAG 3.0 löst WCAG 2.2 nicht ab, sondern wird zunächst neben ihr bestehen. Mein Rat aus der Praxis ist deshalb unmissverständlich: Bauen Sie heute konsequent auf WCAG 2.2 in Stufe AA. Wer auf 3.0 wartet, verschenkt Jahre – und bleibt in dieser Zeit rechtlich angreifbar. Welche neun Kriterien WCAG 2.2 konkret ergänzt, lohnt einen genaueren Blick.
WCAG und das deutsche Recht: BFSG, BITV und EN 301 549
Die WCAG sind selbst kein Gesetz – sie sind der technische Maßstab, auf den Gesetze verweisen. In Deutschland verbindet die europäische Norm EN 301 549 die WCAG mit den rechtlichen Anforderungen. Für die öffentliche Hand gilt die BITV 2.0, für die Privatwirtschaft seit Juni 2025 das Barrierefreiheitsstärkungsgesetz. Beide stützen sich im Kern auf dieselben WCAG-Erfolgskriterien auf Stufe AA.
Das ist die gute Nachricht für Sie: Sie müssen sich nicht in mehrere konkurrierende Regelwerke einarbeiten. Wer seine digitalen Angebote sauber an WCAG 2.2 AA ausrichtet, erfüllt damit die technische Substanz nahezu aller einschlägigen Vorgaben gleichzeitig. Die EN 301 549 erweitert den Anwendungsbereich lediglich über reine Webinhalte hinaus, etwa auf Software und Hardware. Konkret übernimmt die Norm in ihren Web-Kapiteln die WCAG-Erfolgskriterien weitgehend und ergänzt sie um Anforderungen an Hardware, Dokumente und Echtzeitkommunikation – wer sauber nach WCAG 2.2 AA arbeitet, deckt damit bereits den Großteil der Norm ab.
Drei WCAG-Verstöße aus unseren Audits – und ihre Lösung
Statistik wird greifbar, wenn man sie in der Praxis sieht. Drei Fälle, die zeigen, wie aus einem abstrakten Erfolgskriterium ein konkreter Conversion-Blocker wird.
Fall 1 – Der unsichtbare Pflichtfeld-Fehler. Bei einem Versicherer wurden Pflichtfelder im Antragsformular bei einer Fehleingabe rot umrandet – mit einem Rot, das gegen Weiß nur 2,9 zu 1 erreichte und damit Kriterium 1.4.11 für Nicht-Text-Kontrast verfehlte. Nutzer mit Rotsehschwäche sahen die Markierung schlicht nicht und brachen den Abschluss ab. Der entscheidende Punkt: Die meisten Teams prüfen nur den Fließtext-Kontrast und vergessen grafische Elemente wie Feldränder, Icons und den Fokusrahmen selbst. Die Lösung war kein CI-Bruch, sondern das Abdunkeln der Akzentfarbe um wenige Prozent.
Fall 2 – Das selbstgebaute Dropdown. Ein Reiseportal hatte sein Auswahlmenü als gestyltes <div>-Konstrukt gebaut, das mit der Maus tadellos funktionierte. Per Tastatur war es eine Sackgasse – kein Fokus, keine Pfeiltasten-Navigation, kein angesagter Zustand. Das verletzte gleich zwei Kriterien: 2.1.1 (Tastatur) und 4.1.2 (Name, Rolle, Wert). Ein natives <select> oder ein korrekt mit ARIA ausgezeichnetes Pattern hätte das Problem von vornherein vermieden.
Fall 3 – Die zu kleinen Touch-Ziele. Ein Shop hatte auf dem Smartphone Filter-Buttons von 18 Pixeln Kantenlänge – schick, aber unter der mit WCAG 2.2 neuen Schwelle von 24 mal 24 Pixeln (2.5.8). Nutzer mit motorischen Einschränkungen oder einfach großen Fingern trafen daneben. Solche Verstöße entstehen fast immer, weil das neue Kriterium im Design-System noch nicht hinterlegt ist.
Warum ein Scanner nur ein Drittel der WCAG prüft
Ein Wort zur Versuchung, sich auf automatische Tests zu verlassen. Die sechs häufigsten Fehler oben finden Scanner zuverlässig, und ein automatischer Test ist ein sinnvoller erster Schritt. Aber er bleibt eben ein erster Schritt: Automatisierte Werkzeuge erkennen nur etwa 30 bis 40 Prozent der WCAG-Erfolgskriterien. Ob die Tastaturbedienung über einen ganzen Bestellprozess trägt, ob eine Fehlermeldung sinnvoll angesagt wird, ob ein Linktext aus dem Kontext heraus verständlich ist – das erfordert menschliches Urteil. Die Grenzen der Werkzeuge habe ich im Vergleich der Test-Tools mit Beispielen belegt.
Das ARIA-Paradox bringt diese Grenze auf den Punkt: Ein Scanner zählt, ob ein Attribut vorhanden ist – nicht, ob es inhaltlich richtig ist. Genau deshalb können Seiten mit viel, aber schlechter ARIA technisch „bestehen“ und für echte Nutzer trotzdem unbenutzbar sein. Diese Lücke zwischen technischem Bestehen und echter Benutzbarkeit schließt nur ein Audit, bei dem Menschen mit Hilfsmitteln die Seite tatsächlich bedienen – bei uns ist das Access Ready.
Von der WCAG-Theorie zum belastbaren Nachweis
Die Richtlinien geben Ihnen ein präzises Regelwerk an die Hand – aber sie sagen Ihnen nicht, wo Ihr konkretes Angebot heute steht. Und hier liegt die entscheidende Hürde: Jene 60 bis 70 Prozent der WCAG-Kriterien, die sich der Automatisierung entziehen, lassen sich nur durch einen Menschen prüfen, der mit Hilfsmitteln arbeitet.
Deshalb prüfen wir bei Access Ready jedes Erfolgskriterium der WCAG 2.2 AA in einem technischen Tiefen-Audit, kombiniert mit einem Panel echter Nutzer assistiver Technologien. Sie erhalten nach Behebung der Mängel ein rechtlich belastbares Zertifikat, das Ihre WCAG-Konformität nachweisbar und im Streitfall verteidigbar macht. Ich verspreche Ihnen keine perfekte Punktzahl – wohl aber die ehrliche, dokumentierte Gewissheit, auf dem Stand der Technik zu sein. Wenn Sie wissen wollen, welche WCAG-Kriterien Ihr Angebot heute erfüllt und welche nicht, ist ein zertifiziertes WCAG-Audit der direkte Weg dorthin. Den schnellen ersten Überblick, wie viele dieser Kriterien Ihre Website heute reißt, liefert Ihnen vorab unser kostenloser Access Score – ein automatisierter WCAG-2.2-Test in wenigen Minuten. Für den belastbaren Nachweis folgt darauf Access Ready: Wo andere Anbieter Ihnen ein Klick-Widget verkaufen und Sie mit dem Haftungsrisiko allein lassen, bekommen Sie ein dokumentiertes, im Streitfall verteidigbares Ergebnis.
