WCAG steht für Web Content Accessibility Guidelines. Es ist eine Sammlung internationaler Standards, um digitalen Inhalt für Menschen mit Behinderungen zugänglich zu machen, herausgegeben von der W3C Web Accessibility Initiative.

Ist WCAG gesetzlich vorgeschrieben?

Es hängt von deiner Rechtsprechung und davon ab, was du veröffentlichst. In den USA müssen Bundesbehörden WCAG via Section 508 befolgen, und ADA-Title-III-Klagen verweisen routinemäßig auf WCAG 2.1 AA. Staatliche und kommunale Regierungen werden von einer ADA-Title-II-Regel von 2024 abgedeckt. In der Europäischen Union wendet der European Accessibility Act WCAG 2.1 AA seit dem 28. Juni 2025 auf viele private Unternehmen an. Selbst wo es nicht streng erforderlich ist, fragen die meisten Enterprise-Beschaffungsverträge danach.

Was ist der Unterschied zwischen WCAG A, AA und AAA?

Stufe A ist das Minimum und deckt 30 Erfolgskriterien ab. Stufe AA fügt 20 weitere hinzu (50 kumulativ) und ist die Stufe, die in den meisten Gesetzen und Verträgen zitiert wird. Stufe AAA fügt weitere 28 hinzu (78 kumulativ) und ist die höchste Hürde, aber das W3C sagt ausdrücklich, dass vollständiges AAA kein realistisches site-weites Ziel ist. Die meisten Teams streben AA an, mit AAA bei sicherheitskritischen oder besonders wirkungsvollen Inhalten.

WCAG 2.2 ist die aktuell veröffentlichte Version, finalisiert im Oktober 2023. Sie baut auf WCAG 2.1 auf und fügt 9 neue Erfolgskriterien hinzu, die Fokus-Erscheinungsbild, Drag-Bewegungen, Zielgröße, konsistente Hilfe, redundante Eingabe und barrierefreie Authentifizierung abdecken. Die meiste bestehende WCAG 2.1-Arbeit überträgt sich — 2.2 ist additiv, keine Neuschreibung.

Wie prüfe ich, ob meine Site WCAG-konform ist?

Lass automatisierte Tools wie axe DevTools, WAVE oder Lighthouse für die schnellen Gewinne laufen, dann mach einen manuellen Durchgang: Tastaturnavigation, Screenreader (VoiceOver oder NVDA) und Zoom auf 200 %. Automatisierte Tools fangen rund 30 % der Probleme, also ist manuelles Testen unerlässlich. Für hochkritische Arbeit hol einen professionellen Auditor für einen vollständigen WCAG-Konformitätsbericht und ein VPAT.

Was sind die POUR-Prinzipien?

POUR steht für Perceivable, Operable, Understandable und Robust — die vier hochrangigen Prinzipien, unter die jedes WCAG-Erfolgskriterium fällt. Perceivable bedeutet, dass Nutzer den Inhalt wahrnehmen können. Operable bedeutet, dass sie damit interagieren können. Understandable bedeutet, dass Inhalt und UI Sinn ergeben. Robust bedeutet, dass es zuverlässig über Browser und assistive Technik hinweg funktioniert.

Gilt WCAG für mobile Apps?

Ja, im Geiste. WCAG selbst ist web-fokussiert, aber mobile Plattformen lassen sich eng auf dieselben Prinzipien abbilden. Apples Accessibility-Richtlinien und Googles Material-Design-Barrierefreiheits-Doku stehen beide im Einklang mit WCAG. WCAG 3.0, derzeit in Entwicklung, erweitert den Geltungsbereich, um explizit Apps und andere digitale Produkte einzuschließen.

Was ist der schnellste Barrierefreiheits-Gewinn, den ich heute ausliefern kann?

Behebe den Farbkontrast. Es ist der einzelne häufigste WCAG-Fehler (etwa 81 % der Startseiten scheitern daran), das Kriterium ist eindeutig (4,5:1 für Body-Text, 3:1 für großen Text), und die Lösung ist meist nur ein CSS-Farbänderung. Lass deine Textfarben durch unseren Farbkontrast-Checker laufen und du fängst die meisten Probleme in 15 Minuten.

Was ist WCAG? Verständlicher Leitfaden zur Web-Barrierefreiheit (2026)

# Was ist WCAG? Ein verständlicher Leitfaden zur Web-Barrierefreiheit (2026)

WCAG (Web Content Accessibility Guidelines) ist der globale Standard für digitale Barrierefreiheit, herausgegeben vom World Wide Web Consortium (W3C). Die aktuelle Version ist WCAG 2.2, und die meisten Teams streben Konformitätsstufe AA an. Die Richtlinien basieren auf vier Prinzipien — Wahrnehmbar, Bedienbar, Verständlich und Robust — die zusammen abdecken, wie Menschen mit Behinderungen das Web nutzen.

Wenn du 2026 Websites oder Apps baust, wird das Wort „WCAG" auftauchen. Es wird in Design-Reviews auftauchen. Es wird in Sicherheitsfragebögen von Anbietern auftauchen. Und zunehmend wird es in juristischen Schreiben auftauchen. ADA-Title-III-Klagen haben Jahr für Jahr neue Rekorde aufgestellt, der European Accessibility Act (EAA) wurde am 28. Juni 2025 vollstreckbar, und das US-Justizministerium hat eine Regel unter ADA Title II finalisiert, die staatliche und kommunale Regierungen direkt auf WCAG 2.1 Stufe AA verweist.

Das hier ist also die Einführung. Was WCAG eigentlich ist, wer es befolgen muss, was die Stufen und Prinzipien bedeuten und wo du anfängst, wenn du nur einen Nachmittag Zeit hast. Kein Juristendeutsch, kein Fachjargon, nur die Teile, die für barrierefreie Arbeit zählen.

Auf dieser Seite

Der 4-Schritte-Nachmittagsplan — wenn du nur ein paar Stunden hast
Eine kurze Geschichte der WCAG
Für wen WCAG gilt — Gesetze nach Region und Sektor
Die 4 POUR-Prinzipien — Wahrnehmbar, Bedienbar, Verständlich, Robust
WCAG-Stufen: A, AA, AAA — und welche du anstreben solltest
Die am häufigsten verletzten WCAG-Kriterien — die 8 Probleme, die du zuerst beheben solltest
Wie du auf WCAG-Konformität testest — automatisiert, manuell, professionell
Häufige WCAG-Mythen, entlarvt
Was kommt: WCAG 3.0
Ressourcen und wo es weitergeht
FAQ

Der 4-Schritte-Nachmittagsplan

Wenn du einen Nachmittag Zeit hast und maximale Wirkung erzielen willst, bevor du den Rest dieses Leitfadens liest, mach diese vier Dinge der Reihe nach. Jeder Schritt für sich bewegt die Nadel; zusammen beheben sie das meiste, was ein automatisiertes Tool in einem echten Audit kennzeichnen würde.

Lass axe DevTools auf deinen drei meistbesuchten Seiten laufen. Notiere jeden Kontrast- und Label-Fehler.
Behebe jeden Kontrastfehler mit unserem Farbkontrast-Checker. Das allein behebt den am häufigsten verletzten WCAG-Punkt im Web.
Tabbe mit der Tastatur durch jede Seite. Notiere alle Fallen, Sackgassen oder unsichtbaren Fokus-Ringe.
Prüfe Alt-Text auf der Startseite und den Hauptproduktseiten — siehe Bild-Alt-Text, wie es aussehen sollte.

Das allein bringt dich ein gutes Stück Richtung AA. Der Rest dieses Artikels gibt dir das Warum, das Framework und das tiefere Test-Playbook, damit die Arbeit Wirkung zeigt, statt zu Beschäftigungstherapie zu werden.

Eine kurze Geschichte der WCAG

Der Barrierefreiheits-Standard des Webs ist älter als die meisten Frameworks, die du täglich nutzt. Hier ist die grobe Zeitachse:

WCAG 1.0 (1999) — die ursprünglichen Richtlinien. Stark auf HTML fokussiert, geschrieben bevor Single-Page-Apps existierten.
WCAG 2.0 (2008) — die Neuschreibung, die die POUR-Prinzipien und das A/AA/AAA-Konformitätsmodell einführte. Wird in vielen Gesetzen noch zitiert.
WCAG 2.1 (2018) — fügte 17 neue Kriterien hinzu, die Mobil, Sehschwäche und kognitive Behinderungen abdecken.
WCAG 2.2 (2023) — veröffentlicht im Oktober 2023. Fügt 9 neue Kriterien hinzu (Fokus-Erscheinungsbild, Drag-Bewegungen, Zielgröße und mehr).
WCAG 3.0 (in Entwicklung) — ein kompletter Neuentwurf mit einem Bewertungsmodell statt Bestanden/Nicht-Bestanden. Noch ein Arbeitsentwurf, kein festes Veröffentlichungsdatum.

Das W3C ist die Standardisierungsstelle. Innerhalb des W3C übernimmt die Web Accessibility Initiative (WAI) das eigentliche Schreiben. Sowohl Regierungen als auch private Unternehmen zitieren WCAG nach Versionsnummer, also bedeuten „WCAG 2.1 AA" und „WCAG 2.2 AA" in einem Vertrag unterschiedliche (wenn auch ähnliche) Dinge.

Für wen WCAG gilt

Symbole für Regierung, Einzelhandel, Schule und Gesundheitswesen umkreisen einen Globus und zeigen die weite Reichweite der WCAG-Barrierefreiheits-Regeln

Kurze Antwort: 2026 gilt WCAG für viel mehr Sites als früher. Die Reichweite hängt davon ab, wo du operierst und wer deine Nutzer sind.

Regierung und öffentlicher Sektor

In den Vereinigten Staaten verlangt Section 508 des Rehabilitation Act, dass Bundesbehörden und ihre Auftragnehmer WCAG 2.0 Stufe AA erfüllen. Die ADA-Title-II-Regel von 2024 erweitert ähnliche Anforderungen je nach Größe bis 2026 oder 2027 auf staatliche und kommunale Regierungen. Öffentliche Universitäten fallen unter Section 504 des Rehabilitation Act.

In der Europäischen Union unterliegen Stellen des öffentlichen Sektors seit 2018 der Web Accessibility Directive. Diese Direktive verweist über den harmonisierten Standard EN 301 549 auf WCAG 2.1 AA.

Öffentlich zugängliche kommerzielle Sites (ADA Title III)

Das ist der große Punkt für Unternehmen. ADA Title III deckt „Orte der öffentlichen Bereitstellung" ab, und US-Gerichte haben entschieden, dass dies Websites mit klarem Bezug zu einem physischen Geschäft einschließt — und zunehmend Websites für sich allein.

ADA-Title-III-Klagen zur Web-Barrierefreiheit gehen jedes Jahr in die Tausende von Bundesanträgen, wobei Einzelhandel, Gastronomie und Unterhaltung konstant die Spitze anführen — siehe den aktuellen Seyfarth ADA Title III Filings Tracker für die aktuelle Zählung. Die meisten Vergleiche verlangen WCAG 2.1 AA-Konformität mit jährlichen Audits.

European Accessibility Act (EAA)

Der EAA trat am 28. Juni 2025 in Kraft. Er gilt für private Unternehmen, die bestimmte Produkte und Dienstleistungen an EU-Verbraucher verkaufen — E-Commerce, Banking, E-Books, Verkehrs-Ticketing, Telekommunikation und mehr. Selbst wenn du außerhalb der EU sitzt, fällst du wahrscheinlich darunter, wenn du an EU-Verbraucher verkaufst. Die technische Basis ist WCAG 2.1 AA.

Bildung und Gesundheitswesen

Section 504 des Rehabilitation Act und Title II des ADA ziehen die meisten US-Schulen und -Universitäten mit hinein. Gesundheitsdienstleister, die Bundesmittel erhalten (im Grunde alle), fallen unter Section 1557 des Affordable Care Act, der so ausgelegt wurde, dass er WCAG-Konformität für patientenseitige Tools verlangt.

Freiwillige Übernahme

Viele private Unternehmen befolgen WCAG, auch wenn es nicht streng erforderlich ist. Die Gründe reichen von Beschaffung (Enterprise-Kunden fragen nach VPATs) über Talente (barrierefreiheitsbewusste Designer wollen für Firmen arbeiten, die das ernst nehmen) bis hin zu schlichtweg gutem Design — barrierefreie Produkte sind tendenziell für alle klarer.

Die 4 POUR-Prinzipien

Jedes WCAG-Erfolgskriterium fällt unter eines von vier Prinzipien. Das Akronym ist POUR, und sobald du es kennst, ergibt der Rest des Standards viel mehr Sinn.

Wahrnehmbar

Inhalt muss für Nutzer auf eine Weise präsentierbar sein, die sie wahrnehmen können. Wenn ein Nutzer den Inhalt nicht sehen, hören oder anderweitig wahrnehmen kann, zählt nichts anderes.

Dieses Prinzip umfasst Alternativtext für Bilder, Untertitel und Transkripte für Video, Farbkontrast und Inhalte, die sich an assistive Technologien anpassen. Es bedeutet nicht, dass jeder Nutzer jeden Sinn nutzen können muss — es bedeutet, dass es immer mindestens einen Weg gibt, den Inhalt wahrzunehmen.

Zwei Beispiel-Erfolgskriterien:

1.1.1 Nicht-Text-Inhalt (Stufe A) — jedes Bild, Symbol und Diagramm hat eine Textalternative. Wir gehen darauf in unserem Bild-Alt-Text-Leitfaden genauer ein.
1.4.3 Kontrast (Minimum) (Stufe AA) — Text braucht ein Kontrastverhältnis von mindestens 4,5:1 gegenüber seinem Hintergrund (3:1 für großen Text). Für die ausführliche Erklärung siehe Farbkontrast und WCAG.

Bedienbar

Nutzer müssen die Oberfläche bedienen können. Tastatur, Maus, Touch, Sprache — egal welche sie nutzen, die Seite muss reagieren.

Hier wohnt die Tastaturnavigation. Hier finden sich auch Regeln zur Gewährung ausreichender Zeit, zur Vermeidung von Anfälle auslösendem Blinken und zur Hilfe für Menschen, sich mit Sprung-Links und klaren Fokus-Ringen zurechtzufinden.

Zwei Beispiel-Erfolgskriterien:

2.1.1 Tastatur (Stufe A) — alle Funktionalität muss allein per Tastatur funktionieren, keine Maus erforderlich.
2.4.7 Fokus sichtbar (Stufe AA) — wenn ein Element den Tastatur-Fokus erhält, muss der Fokus-Zustand sichtbar sein. Standard-Fokus-Ringe zu entfernen, ohne sie zu ersetzen, ist eine klassische Verletzung.

Verständlich

Inhalt und Oberfläche müssen verständlich sein. Das umfasst lesbaren Text, vorhersehbare Navigation und hilfreiche Fehlermeldungen in Formularen.

Verständlich bedeutet nicht vereinfacht. Es bedeutet konsistent — Buttons, die wie Buttons aussehen, Beschriftungen, die sagen, was sie tun, und Formulare, die erklären, was schiefging, statt einfach rot zu werden.

Zwei Beispiel-Erfolgskriterien:

3.1.1 Sprache der Seite (Stufe A) — setze ein lang-Attribut auf das -Element, damit Screenreader den Inhalt korrekt aussprechen.
3.3.2 Beschriftungen oder Anweisungen (Stufe A) — jedes Formularfeld braucht eine sichtbare Beschriftung oder klare Anweisungen, nicht nur Platzhaltertext.

Robust

Inhalt muss über User-Agents hinweg funktionieren — aktuelle Browser, aktuelle Screenreader und die assistive Technik in fünf Jahren. In der Praxis ist das das Prinzip, das sagt „nutze semantisches HTML und gültiges ARIA".

Wenn du ein eigenes Dropdown aus

-Tags mit Klick-Handlern baust und Tastatur und ARIA-Rollen überspringst, scheiterst du an diesem Prinzip. Robust ist auch der Grund, warum Screenreader-Teams sich so um sauberes Markup kümmern.

Zwei Beispiel-Erfolgskriterien:

4.1.2 Name, Rolle, Wert (Stufe A) — jedes interaktive Element legt einen Namen, eine Rolle und jeden Zustand für assistive Technik offen. Eigene Komponenten müssen das durch ARIA tun.
4.1.3 Statusmeldungen (Stufe AA) — Toast-Benachrichtigungen, Formularvalidierung und andere Status-Updates müssen Screenreadern angekündigt werden, ohne den Fokus zu wechseln.

WCAG-Stufen: A, AA, AAA

Drei aufsteigende Stufen auf einem Podium, die die WCAG-Konformitätsstufen A, AA und AAA darstellen, mit Plaketten, die über jeder Stufe schweben

WCAG hat drei Konformitätsstufen. Jede ist eine höhere Hürde, und jede höhere Hürde umfasst alles darunter. In WCAG 2.2 verteilen sich die Kriterien wie folgt:

Stufe	Kriterien	Was es bedeutet
A	30	Das Minimum. Wenn eines davon nicht erfüllt ist, wird der Inhalt für manche Menschen unbenutzbar.
AA	50 (kumulativ)	Der Industriestandard und die Stufe, die die meisten Gesetze fordern.
AAA	28 (kumulativ 78)	Erweiterte Barrierefreiheit. Nicht jeder Inhalt kann das erfüllen.

Stufe A — die Untergrenze

Stufe-A-Kriterien sind grundlegend. Sie decken Dinge ab wie „Bilder haben Alt-Text", „Video hat Untertitel", „die Seite funktioniert ohne Maus" und „du nutzt nicht Farbe allein, um Information zu vermitteln". Wenn du Stufe A nicht erfüllst, sind echte Nutzer ausgesperrt.

Du solltest Stufe A als absolutes Minimum betrachten. Keine ernsthafte Organisation gibt Stufe A als ihr Ziel an — es ist das, was du auf dem Weg zu AA erreichst.

Stufe AA — der Standard

Stufe AA ist die Stufe, die in ADA-Vergleichen, im EAA, in Section 508 und den meisten Beschaffungsverträgen zitiert wird. Wenn jemand sagt, eine Site sei „WCAG-konform", meint er fast immer AA.

AA fügt strengere Kontrastanforderungen hinzu, Untertitel für Live-Video, Fokus-Indikatoren, konsistente Navigation und Skalierbarkeit ohne Inhaltsverlust. Sie ist für nahezu alle Inhalte erreichbar, und sie zu erfüllen bringt dich den größten Teil des Wegs zu echter Barrierefreiheit.

Stufe AAA — die Decke

AAA ist der Goldstandard. Sie umfasst Dinge wie 7:1-Kontrast für normalen Text, Gebärdensprach-Dolmetschen für aufgezeichnetes Video und Lesestufe nicht höher als Sekundarstufe I.

Das W3C sagt ausdrücklich, du solltest keine vollständige AAA-Konformität für ganze Websites anstreben, weil manche Kriterien für manche Inhalte schlicht nicht erfüllbar sind. Stattdessen zielen Teams auf „AA + etwas AAA, wo es zählt" — etwa AAA-Kontrast bei sicherheitskritischen Schnittstellen oder AAA-Lesestufe auf Regierungs-Informationsseiten.

Wenn dir jemand sagt, ihre Site sei „WCAG AA konform", ist das in 95 Prozent der Fälle die richtige Antwort. AAA-Behauptungen sollten dich Folgefragen stellen lassen.

Gesponsert von den Machern

Genug von langweiligen Screenshots? Probier ScreenSnap Pro.

Wunderschöne Hintergründe, professionelle Annotationen, GIF-Aufnahme und sofortiges Cloud-Sharing — alles in einer App. Einmalig 39 $, für immer deins.

Sieh, was es kann

Die am häufigsten verletzten WCAG-Kriterien

Raster typischer Web-Barrierefreiheits-Verletzungen: kontrastarmer Text, fehlender Alt-Text, kaputte Tastatur, unbeschriftetes Formular, versteckter Fokus-Ring und generische Links

WebAIM veröffentlicht eine jährliche Analyse der Top-Eine-Million-Startseiten. Dieselbe Handvoll Probleme taucht Jahr für Jahr auf. Wenn du diese behebst, hast du den Großteil der Arbeit getan.

1. Niedriger Farbkontrast (1.4.3)

Der einzelne häufigste WCAG-Fehler. WebAIMs jährliche Million-Analyse findet konstant kontrastarmen Text auf etwa 80 % der Startseiten. Diese Quote hat sich seit Jahren kaum bewegt.

Die Regel selbst ist einfach. Normaler Text braucht ein 4,5:1-Kontrastverhältnis gegenüber seinem Hintergrund. Großer Text (24 px oder 18,66 px fett und mehr) braucht 3:1. Logos und beiläufige Dekoration sind ausgenommen.

Das Problem ist, dass Designer hellgrau auf weiß lieben. Es fühlt sich modern an. Es scheitert auch in Sekunden an AA. Lass jeden Link, Body-Text oder gedämpften Hilfstext durch unseren kostenlosen Farbkontrast-Checker laufen oder lies den ausführlicheren Erklärer unter Farbkontrast und WCAG für Verhältnisse, Formeln und durchgearbeitete Lösungen.

2. Fehlender Alt-Text (1.1.1)

Der zweithäufigste Fehler: Bilder ohne alt-Attribute oder mit Platzhaltern wie alt="image" oder alt="picture". Beides sind Barrieren — das erste lässt Screenreader-Nutzer raten, das zweite verschwendet ihre Zeit mit Lärm.

Nützlicher Alt-Text beschreibt den Zweck des Bildes, nicht nur seinen Inhalt. Dekorative Bilder bekommen alt="" (leer, aber das Attribut ist da). Für alles andere geht unser Bild-Alt-Text-Leitfaden die Regeln durch.

3. Formular-Beschriftungen fehlen oder falsch (1.3.1, 3.3.2)

Formulare scheitern an WCAG, wenn Felder sichtbare Beschriftungen vermissen, wenn Beschriftungen nicht programmatisch mit Eingaben verbunden sind oder wenn Platzhaltertext als Beschriftung verwendet wird. Sobald der Platzhalter beim Fokus verschwindet, haben Screenreader-Nutzer keine Möglichkeit zu wissen, wofür das Feld da ist.

Die Lösung ist ein HTML-Attribut: Email gepaart mit . Oder umschließe die Eingabe mit dem Label. Beides funktioniert.

4. Tastatur-Unzugänglichkeit (2.1.1)

Eigene Komponenten, die mit

und Klick-Handlern gebaut sind — Modale, Menüs, Tabs, Slider — scheitern fast immer am Tastaturzugang. Tabbe rein, und nichts passiert. Tabbe vorbei, und du bist gefangen.

Die pragmatische Lösung ist, echte Elemente zu verwenden: