NCA Social Media
Erstellt:
Aktualisiert:
Autor:
Roland Golla
Web Content Accessibility Guidelines (WCAG)

Was sind die Web Content Accessibility Guidelines (WCAG)?

Die Web Content Accessibility Guidelines (WCAG) sind der internationale Standard für barrierefreie Webinhalte. Das W3C legt darin mit prüfbaren Erfolgskriterien fest, wie Websites, Web Apps und digitale Dokumente für Menschen mit Behinderungen nutzbar werden.
Aktuell gilt WCAG 2.2 mit 86 Erfolgskriterien in den drei Konformitätsstufen A, AA und AAA. In Europa ist Stufe AA der Maßstab: Über die Norm EN 301 549 sind die WCAG die technische Grundlage für das Barrierefreiheitsstärkungsgesetz (BFSG) und die BITV 2.0.
Wer nach WCAG baut, hilft nicht nur Menschen mit Screenreader. Klare Struktur, starke Kontraste und volle Tastaturbedienung helfen allen. Etwa auf dem Smartphone in der Sonne, mit einer Hand am Kinderwagen oder mit müden Augen am Abend.
Inhalt

WCAG mit NCA: Schnelle Hilfe vom Experten

Never Code Alone testet seit über 20 Jahren Software auf Qualität. Barrierefreiheit gehört für uns in denselben Werkzeugkasten wie Unit Tests und statische Analyse. In unseren Frontends mit Astro, React und Vue prüfen wir WCAG Kriterien automatisiert mit Cypress und axe in der CI Pipeline. Die Punkte, die kein Tool findet, prüfen wir von Hand mit Tastatur und Screenreader.
Wir helfen Teams beim barrierefreien Webdesign, bei einem Accessibility Audit bestehender Anwendungen und beim Aufbau von axe DevTools und Cypress Accessibility Tests. Dazu kommen saubere ARIA Patterns, barrierefreie Formulare und die Einordnung, was das BFSG für euer Projekt konkret bedeutet.
WCAG 2.2 AA in eurem Projekt umsetzen
Finde das passende Angebot für dein Projekt
Anfrage-Konfiguration
Starten Sie Ihre Anfrage
Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

So sind die WCAG aufgebaut

Die WCAG wirken auf den ersten Blick wie ein dicker Katalog. Dahinter steckt aber eine klare Ordnung in vier Ebenen. Wer sie einmal verstanden hat, findet sich schnell zurecht.
  • Prinzipien: Vier Grundideen bilden das Dach. Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein.
  • Richtlinien: Unter den Prinzipien stehen 13 Richtlinien, etwa Textalternativen, Tastaturbedienung oder Lesbarkeit.
  • Erfolgskriterien: Jede Richtlinie hat prüfbare Kriterien mit Nummer, zum Beispiel 1.4.3 Kontrast (Minimum). Nur diese Kriterien zählen für die Konformität.
  • Techniken: Das W3C beschreibt dazu Techniken und typische Fehler. Sie zeigen, wie ein Kriterium in HTML, CSS oder ARIA erfüllt wird.
Die WCAG sind technikneutral formuliert. Deshalb gelten sie nicht nur für klassische Websites, sondern auch für Web Apps, PDF Dokumente und über die EN 301 549 sogar für native Apps und Software.

Die vier Prinzipien der WCAG: POUR

Alle Erfolgskriterien hängen an vier Prinzipien. Im Englischen ergeben sie das Kürzel POUR. Wer bei einem Fehler fragt, welches Prinzip verletzt ist, findet meist schnell die Ursache. Mehr dazu steht im Artikel zu den vier Grundprinzipien POUR.
Wahrnehmbar (Perceivable): Jede Information muss über mindestens einen Sinn erreichbar sein. Bilder brauchen einen Alternativtext, Videos Untertitel und Texte einen ausreichenden Farbkontrast.
Bedienbar (Operable): Alles muss ohne Maus funktionieren. Keyboard Navigation, sichtbarer Fokus, genug Zeit und keine blinkenden Inhalte gehören dazu.
Verständlich (Understandable): Sprache, Navigation und Formulare müssen nachvollziehbar sein. Fehlermeldungen sagen klar, was schiefging und wie man es behebt.
Robust: Der Code muss so sauber sein, dass Browser und assistive Technologien ihn zuverlässig lesen. Semantic HTML und korrekte Werte für Name, Rolle und Zustand sind hier die Basis.

Konformitätsstufen A, AA und AAA

Jedes Erfolgskriterium gehört zu einer von drei Stufen. Die Stufen bauen aufeinander auf. Wer AA erreichen will, muss alle Kriterien aus A und AA erfüllen.
  • Stufe A: Die Grundlage. Ohne diese Kriterien sind Inhalte für manche Menschen gar nicht nutzbar, etwa ohne Textalternativen oder ohne Tastaturbedienung.
  • Stufe AA: Der Standard für Gesetze und Normen. Hier kommen unter anderem Mindestkontraste, sichtbarer Fokus und eine Mindestgröße für Klickziele dazu.
  • Stufe AAA: Die höchste Stufe mit strengen Anforderungen wie Gebärdensprache für Videos. Das W3C empfiehlt AAA nicht als Pflicht für ganze Websites, weil sich nicht jeder Inhalt so umsetzen lässt.
Eine Konformität gilt immer für ganze Seiten und vollständige Prozesse. Ein barrierefreier Warenkorb nützt wenig, wenn der letzte Schritt im Checkout nur mit der Maus klappt. Was eine saubere Konformität ausmacht, erklären wir im eigenen Glossar Artikel.

WCAG Versionen: Von 2.0 bis 3.0

Die WCAG wachsen mit dem Web. Jede neue Version der 2er Reihe ist abwärtskompatibel. Wer WCAG 2.2 erfüllt, erfüllt damit automatisch auch 2.1 und 2.0. Das macht den Umstieg planbar: Neue Kriterien kommen dazu, alte bleiben gültig.
Eine Ausnahme gibt es. Das Kriterium 4.1.1 Parsing ist in WCAG 2.2 entfallen, weil moderne Browser fehlerhaftes HTML inzwischen einheitlich verarbeiten. Prüfprotokolle und Tools, die Parsing noch als Fehler zählen, solltet ihr aktualisieren.

WCAG Versionen im Überblick

Version Status und Umfang Schwerpunkt
WCAG 2.0 W3C Empfehlung seit 2008, 61 Erfolgskriterien Grundlage mit vier Prinzipien und drei Stufen
WCAG 2.1 W3C Empfehlung seit 2018, 78 Erfolgskriterien Mobile Nutzung, Sehbehinderung, kognitive Einschränkungen
WCAG 2.2 W3C Empfehlung seit 2023, 86 Erfolgskriterien Fokus, Klickziele, Hilfe und Anmeldung
WCAG 3.0 Working Draft des W3C, noch nicht verbindlich Neues Konformitätsmodell, breiterer Geltungsbereich

Neu in WCAG 2.2: Die neun Erfolgskriterien

WCAG 2.2 bringt neun neue Kriterien. Sechs davon liegen auf Stufe A und AA und zählen damit für Gesetze und Normen. Sie helfen vor allem Menschen, die mit Tastatur, auf dem Touchscreen oder mit kognitiven Einschränkungen unterwegs sind.
  • 2.4.11 Fokus nicht verdeckt, Minimum (AA): Sticky Header, Cookie Banner oder Chat Widgets dürfen das fokussierte Element nicht komplett verdecken.
  • 2.5.7 Ziehbewegungen (AA): Wer Drag and Drop anbietet, braucht eine Alternative mit einfachem Klick oder Tippen.
  • 2.5.8 Zielgröße, Minimum (AA): Klickziele brauchen mindestens 24 mal 24 CSS Pixel oder genug Abstand zu Nachbarn.
  • 3.2.6 Konsistente Hilfe (A): Hilfe wie Kontakt oder Chat steht auf allen Seiten an derselben Stelle.
  • 3.3.7 Redundante Eingabe (A): Schon eingegebene Daten werden im selben Prozess nicht erneut abgefragt.
  • 3.3.8 Barrierefreie Authentifizierung, Minimum (AA): Anmelden klappt ohne Rätsel oder Gedächtnistest. Passwort Manager und Einfügen müssen funktionieren.
Dazu kommen drei Kriterien auf Stufe AAA: 2.4.12 Fokus nicht verdeckt (Enhanced), 2.4.13 Fokus Erscheinung und 3.3.9 Barrierefreie Authentifizierung (Enhanced). Sie sind kein Muss, zeigen aber, wohin die Reise geht. Gerade ein gut sichtbarer Fokus lohnt sich für jedes Projekt.

WCAG, EN 301 549, BFSG und BITV: So hängt alles zusammen

Die WCAG selbst sind kein Gesetz. Sie sind eine Empfehlung des W3C. Verbindlich werden sie erst über eine Kette aus Recht und Norm. Wer diese Kette kennt, weiß genau, woran seine Website gemessen wird.
  • European Accessibility Act: Der European Accessibility Act (EAA) verlangt barrierefreie Produkte und Dienstleistungen in der EU.
  • BFSG: Das Barrierefreiheitsstärkungsgesetz setzt den EAA in Deutschland um, etwa für Onlineshops, Banking und Buchungsstrecken.
  • BITV 2.0: Sie regelt die Barrierefreiheit für öffentliche Stellen des Bundes.
  • EN 301 549: Die harmonisierte europäische Norm liefert die technischen Anforderungen. Für Webinhalte verweist sie direkt auf die WCAG Kriterien der Stufen A und AA.
Die EN 301 549 ist gerade im Wechsel. Die neue Version 4.1.1 ist veröffentlicht und stellt von WCAG 2.1 AA auf WCAG 2.2 AA um. Rechtlich maßgeblich wird sie, sobald die EU ihre Fundstelle im Amtsblatt veröffentlicht. Bis dahin bleibt Version 3.2.1 mit WCAG 2.1 AA die Referenz.
Für die Praxis heißt das: Baut und testet gleich gegen WCAG 2.2 AA. Damit seid ihr für die aktuelle und die kommende Norm gerüstet. Welche Fristen und Pflichten für Unternehmen gelten, zeigt unser Artikel zur Compliance in der Barrierefreiheit.

WCAG prüfen: Automatisiert und von Hand

WCAG Konformität entsteht nicht mit einem einzigen Scan. Automatisierte Tools finden technische Fehler schnell und zuverlässig. Ob ein Alternativtext sinnvoll ist oder die Fokus Reihenfolge logisch, entscheidet aber ein Mensch. Gute Teams kombinieren deshalb beides.
Im Browser liefern Google Lighthouse und die Firefox Accessibility Tools einen schnellen ersten Blick. Dauerhaft sicher wird es erst in der Pipeline. Mit cypress-axe läuft jeder Pull Request gegen die WCAG Regeln von axe core:
Code: 
          
describe('Barrierefreiheit Startseite', () => {
  it('hat keine Verstöße gegen WCAG 2.2 AA', () => {
    cy.visit('/')
    cy.injectAxe()
    cy.checkA11y(null, {
      runOnly: {
        type: 'tag',
        values: ['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa']
      }
    })
  })
})
Die Tags begrenzen den Scan auf die Kriterien der Stufen A und AA aus allen drei 2er Versionen. Schlägt der Test fehl, stoppt die Pipeline. So rutscht kein neuer Fehler mehr in Production.
Danach folgt der manuelle Teil: einmal komplett mit der Tastatur durch die wichtigsten User Journeys, dann mit einem Screenreader wie NVDA oder VoiceOver. Die Tab Reihenfolge macht taba11y sichtbar. Wie ein strukturierter Ablauf aussieht, beschreibt unser Artikel zum Accessibility Testing.

WCAG 3.0: Was kommt und was bleibt

Das W3C arbeitet an WCAG 3.0. Schon der Name ändert sich: Aus Web Content Accessibility Guidelines werden die W3C Accessibility Guidelines. Das zeigt den größeren Anspruch. Neben Websites sollen auch Apps, Software und ganze Prozesse erfasst werden.
Die bekannten Stufen A, AA und AAA verschwinden in 3.0. An ihre Stelle tritt ein neues Konformitätsmodell mit Kernanforderungen und ergänzenden Anforderungen. Bewertet werden eher Ansichten und Abläufe als einzelne Seiten. Das Modell ist aber noch in Arbeit und ändert sich von Entwurf zu Entwurf.
Wichtig für eure Planung: WCAG 3.0 ist ein Working Draft und nirgends rechtlich gefordert. Das W3C rechnet mit mehreren Jahren bis zur fertigen Empfehlung und will WCAG 2.x danach nicht zurückziehen. Wer heute WCAG 2.2 AA sauber umsetzt, legt laut aktuellem Entwurf bereits das Fundament für den Großteil der künftigen Mindestanforderungen.

Typische WCAG Fehler und wie ihr sie vermeidet

Viele WCAG Verstöße sind keine großen Architekturprobleme. Es sind Kleinigkeiten, die sich über Jahre in Templates und Komponenten einschleichen. Die gute Nachricht: Wer sie einmal in der Komponente behebt, behebt sie überall.
  • Zu wenig Kontrast: Graue Schrift auf weißem Grund sieht edel aus, fällt aber durch 1.4.3. Hilfe gibt der Artikel zu Color Accessibility.
  • Fehlende Alternativtexte: Bilder ohne alt Attribut oder mit Dateinamen als Text verletzen 1.1.1.
  • Unsichtbarer Fokus: Ein globales outline none im CSS macht die Tastaturbedienung zum Blindflug.
  • Formulare ohne Label: Platzhalter ersetzen keine Beschriftung. Screenreader brauchen ein echtes label Element.
  • Kaputte Überschriften: Überschriften nach Optik statt nach Struktur verwirren Screenreader Nutzer. Mehr dazu unter barrierefreie Headlines.
  • Div statt Button: Klickbare div Elemente sind per Tastatur nicht erreichbar. Ein echtes button Element löst das ohne ARIA.

Access by everyone regardless of disability is an essential aspect.

Tim Berners-Lee, Erfinder des World Wide Web, damals Direktor des W3C – W3C Pressemitteilung zum Start der Web Accessibility Initiative

WCAG in NCA Projekten

Bei uns ist WCAG kein Projekt am Ende, sondern Teil jedes Pull Requests. Barrierefreiheit behandeln wir wie jede andere Qualitätsanforderung: mit festen Regeln, automatisierten Tests und einem Review durch Menschen. So bleibt eine Website barrierefrei, auch wenn das Team neue Features baut.
Den Anfang macht die Struktur. Semantic HTML, eine saubere Lesereihenfolge und barrierefreie Schriftarten lösen viele Kriterien, bevor überhaupt ARIA ins Spiel kommt. Für Farben nutzen wir den Farbkontrast Rechner schon im Design.
Für bestehende Anwendungen starten wir mit einem Accessibility Audit auf Basis einer repräsentativen Stichprobe. Die Ergebnisse fließen auf Wunsch in einen Accessibility Conformance Report. Danach sichern Quality Gates in der Pipeline ab, dass behobene Fehler nicht zurückkommen. Den Aufwand schätzen wir nach einem kostenlosen Kennenlernen und rechnen transparent pro Minute ab.
CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.
Erreichen Sie unsere Spezialisten zu barrierefreien Webdesign

Wir sind hier, um Ihnen zu helfen. Gemeinsam meistern wir Ihre digitalen Herausforderungen und fördern die Inklusion im Internet. Lassen Sie uns Ihre Projekte mit barrierefreiem Webdesign erfolgreich machen.

Kostenlose Demo Jetzt anrufen

Häufige Fragen zu WCAG

Die wichtigsten Antworten zu Versionen, Stufen, Pflichten und Tests rund um die Web Content Accessibility Guidelines.
Welche WCAG Version gilt 2026?

Maßgeblich ist 2026 WCAG 2.2 auf Stufe AA. Das W3C führt WCAG 2.2 als aktuelle Empfehlung, und die neue EN 301 549 in Version 4.1.1 übernimmt sie für Europa. Rechtlich gilt bis zur Nennung der neuen Norm im EU Amtsblatt noch WCAG 2.1 AA über die ältere Version 3.2.1. Wer gegen WCAG 2.2 AA testet, erfüllt beide Stände.

Ist WCAG 2.2 AA 2026 für Onlineshops Pflicht?

Indirekt ja. Das BFSG verlangt barrierefreie Onlineshops und digitale Dienstleistungen für Verbraucher. Technisch gemessen wird das an der EN 301 549, die für Webinhalte auf die WCAG Stufen A und AA verweist. Kleinstunternehmen, die Dienstleistungen anbieten, sind ausgenommen. Mit WCAG 2.2 AA seid ihr auch dann auf der sicheren Seite, wenn die neue Norm verbindlich wird.

Muss ich 2026 schon auf WCAG 3.0 umstellen?

Nein, eine Umstellung ist 2026 nicht nötig. WCAG 3.0 ist ein Working Draft des W3C und in keinem Gesetz gefordert. Bis zur fertigen Empfehlung rechnet das W3C mit mehreren Jahren, und WCAG 2.x wird danach nicht zurückgezogen. Wer jetzt WCAG 2.2 AA umsetzt, schafft laut aktuellem Entwurf die Basis für den Großteil der künftigen Mindestanforderungen.

Was ändert sich 2026 mit der neuen EN 301 549 für die WCAG?

Die EN 301 549 in Version 4.1.1 stellt von WCAG 2.1 auf WCAG 2.2 um. Damit kommen sechs Kriterien der Stufen A und AA dazu, etwa zur Größe von Klickzielen, zum verdeckten Fokus und zur barrierefreien Anmeldung. Das Kriterium 4.1.1 Parsing entfällt. Neu ist außerdem ein Anhang, der die Anforderungen direkt dem European Accessibility Act zuordnet.

Welche Tools prüfen WCAG 2026 zuverlässig?

Für den automatisierten Teil haben sich 2026 axe core, cypress-axe, Pa11y und Lighthouse bewährt. Sie finden technische Fehler wie fehlende Labels oder zu wenig Kontrast. Eine vollständige Prüfung ersetzen sie nicht. Tastaturtests, Screenreader wie NVDA oder VoiceOver und ein menschliches Review bleiben nötig, weil viele Kriterien ein inhaltliches Urteil verlangen.

Was bedeutet WCAG AA?

AA ist die mittlere der drei Konformitätsstufen und der Standard für Gesetze und Normen. Eine Seite erfüllt AA, wenn sie alle Kriterien der Stufen A und AA einhält. Dazu gehören unter anderem ein Kontrast von mindestens 4,5 zu 1 für normalen Text, ein sichtbarer Fokus und eine vollständige Bedienung per Tastatur.

Wofür steht POUR in den WCAG?

POUR steht für die vier Prinzipien der WCAG: Perceivable, Operable, Understandable und Robust. Auf Deutsch heißen sie wahrnehmbar, bedienbar, verständlich und robust. Jedes Erfolgskriterium gehört zu genau einem dieser Prinzipien. Das hilft bei der Fehlersuche, weil sich jede Barriere einer klaren Grundidee zuordnen lässt.

Muss ich WCAG AAA erfüllen?

Nein, in der Regel nicht. Weder BFSG noch EN 301 549 verlangen Stufe AAA. Auch das W3C rät davon ab, AAA als Pflicht für ganze Websites festzulegen, weil manche Inhalte diese Kriterien gar nicht erfüllen können. Einzelne AAA Kriterien wie ein besonders gut sichtbarer Fokus lohnen sich trotzdem für viele Projekte.

Was ist der Unterschied zwischen WCAG und BITV?

Die WCAG sind eine internationale Empfehlung des W3C. Die BITV 2.0 ist eine deutsche Verordnung für öffentliche Stellen des Bundes. Sie schreibt Behörden Barrierefreiheit vor und verweist technisch auf die EN 301 549 und damit auf die WCAG. Die WCAG liefern also die Prüfkriterien, die BITV liefert die Pflicht.

Gelten die WCAG auch für Apps und PDF Dokumente?

Ja. Die WCAG sind technikneutral formuliert und gelten für alle Webinhalte, auch für PDF Dateien auf einer Website. Die EN 301 549 überträgt die Kriterien zusätzlich auf Dokumente außerhalb des Webs und auf Software wie native Apps. Für PDFs kommt der Standard PDF/UA hinzu, damit Screenreader die Struktur korrekt lesen.

Wie viele Erfolgskriterien hat WCAG 2.2?

WCAG 2.2 hat 86 Erfolgskriterien. Neun davon sind gegenüber WCAG 2.1 neu, das Kriterium 4.1.1 Parsing ist entfallen. Die Kriterien verteilen sich auf 13 Richtlinien unter den vier Prinzipien. Für die gängige Konformität auf Stufe AA zählen nur die Kriterien der Stufen A und AA, nicht die AAA Kriterien.

Reicht ein Accessibility Overlay für WCAG Konformität?

Nein. Overlays sind Skripte, die eine Website nachträglich per JavaScript anpassen. Sie beheben keine Fehler im Quellcode und können assistive Technologien sogar stören. WCAG Konformität entsteht nur im Code selbst: mit Semantic HTML, korrekten Labels, ausreichendem Kontrast und sauberer Tastaturbedienung. Das gilt genauso für die Anforderungen aus dem BFSG.

Wie oft sollte man eine Website auf WCAG prüfen?

Am besten bei jeder Änderung. Automatisierte Tests mit cypress-axe oder Pa11y laufen in der CI Pipeline bei jedem Pull Request. Ein manueller Test mit Tastatur und Screenreader lohnt sich bei neuen Komponenten und größeren Releases. Ein vollständiges Audit ist sinnvoll, wenn sich Design, Framework oder rechtliche Anforderungen deutlich ändern.