WCAG 3.0: Was es ist und was es für Ihre WCAG 2.2-Konformität bedeutet

Die Standards für Barrierefreiheit haben sich mit der Weiterentwicklung des Webs verändert. Seit Jahren dient die WCAG-2-Reihe Organisationen als Leitfaden, um ihre Websites und digitale Inhalte für Menschen mit Behinderungen zugänglich zu machen. 

Der WCAG 2.1 AA-Standard wurde zu einem weit verbreiteten Maßstab, gefolgt von WCAG 2.2, das neue Erfolgskriterien in Bereichen wie Fokusdarstellung, Ziehbewegungen, Zielgröße und barrierefreie Authentifizierung hinzufügte. Doch digitale Erlebnisse beschränken sich längst nicht mehr auf statische Webseiten. 

Websites verhalten sich heute eher wie Anwendungen. Inhalte werden geräteübergreifend bereitgestellt, und Technologien wie Sprachschnittstellen, immersive Erlebnisse und KI verändern die Art und Weise, wie Menschen mit digitalen Inhalten interagieren. Hier kommt WCAG 3.0 ins Spiel. 

Der aktuelle WCAG 3.0-Entwurf, der am 3. März 2026 vom World Wide Web Consortium (W3C) veröffentlicht wurde, schlägt einen breiteren Anwendungsbereich, eine andere Struktur und einen neuen Ansatz zur Messung der Barrierefreiheit vor. 

Dieser Artikel befasst sich damit, was sich im Vergleich zu WCAG 2.1 tatsächlich ändert, warum dies wichtig ist und wie Sie Ihre Organisation darauf vorbereiten können.

Das WCAG-POUR-Prinzip

Bevor wir uns eingehend mit WCAG 3.0 befassen, ist es wichtig, die Grundlagen zu verstehen, auf denen moderne Leitlinien zur Barrierefreiheit basieren. 

Die WCAG-Richtlinien für barrierefreie Webinhalte basieren auf vier Prinzipien, die allgemein als POUR.

Wahrnehmbar: Inhalte und Informationen sollten in einer für Nutzer wahrnehmbaren Form bereitgestellt werden, beispielsweise durch Textalternativen für Bilder und Untertitel für Videos. 

Bedienbar: Nutzer sollten in der Lage sein, mithilfe verschiedener Eingabemethoden, einschließlich einer Tastatur, auf einer Website zu navigieren und mit ihr zu interagieren. 

Verständlich: Inhalte, Navigation und Interaktionen sollten klar, vorhersehbar und leicht nachvollziehbar sein. 

Robust: Websites sollten über verschiedene Browser, Geräte und assistive Technologien hinweg zuverlässig funktionieren.

Was sind die WCAG 3.0?

Die WCAG 3.0 sind die vom W3C vorgeschlagenen Leitlinien zur Barrierefreiheit der nächsten Generation. 

Im Gegensatz zu WCAG 2 heißt es „W3C-Barrierefreiheitsrichtlinien“, da sein Anwendungsbereich über Webinhalte hinausgeht – eine Veränderung, die erstmals im ursprünglichen Arbeitsentwurf von 2021 dargelegt wurde. Der aktuelle WCAG-3.0-Entwurf gilt für Webinhalte, Apps, Tools, Veröffentlichungen und neue Technologien. 

Er berücksichtigt zudem verschiedene Arten von Inhalten und Nutzererfahrungen. Dazu gehören dynamische und interaktive Inhalte, audiovisuelle Medien, mobile und tragbare Geräte sowie virtuelle und erweiterte Realität. Das vorgeschlagene Modell befindet sich noch in der Entwicklung. 

Die Fertigstellung des Standards ist noch Jahre entfernt, und es gibt noch kein bestätigtes Veröffentlichungsdatum für WCAG 3.0. Bis dahin bleibt WCAG 2.2 die aktuelle W3C-Empfehlung für Barrierefreiheit im Web.

Was die WCAG 3.0-Richtlinien im Vergleich zu WCAG 2.1 abdecken

Die WCAG 3.0-Richtlinien sind nicht einfach nur eine längere Checkliste mit Anforderungen an die Barrierefreiheit. Im Vergleich zu WCAG 2.1 verändern sie die Art und Weise, wie Barrierefreiheit verstanden, gemessen und aufrechterhalten wird.

1. Ein breiteres Spektrum an Nutzerbedürfnissen

WCAG 2.x hat sich als äußerst wirksam erwiesen, doch lassen sich manche Anforderungen an die Barrierefreiheit nicht eindeutig in ein einfaches „Bestanden/Nicht bestanden“-Erfolgskriterium einordnen. Der Entwurf zu WCAG 3.0 widmet der kognitiven Barrierefreiheit und Sehbehinderungen besondere Aufmerksamkeit. Er untersucht Möglichkeiten, Barrierefreiheit anhand verschiedener Nachweise zu bewerten, anstatt sich ausschließlich auf binäre Tests zu stützen.

2. Ein neuer Ansatz zur Konformität

WCAG 2.1 AA und die darauf folgende Version verwenden die bekannten Stufen A, AA und AAA. WCAG 3.0 untersucht ein anderes Modell. Der aktuelle Entwurf beschreibt die Stufen Bronze, Silber und Gold, die auf Kernanforderungen sowie ergänzenden Anforderungen und Aussagen basieren. Damit soll eine flexiblere Möglichkeit geschaffen werden, verschiedene Grade und Arten von Barrierefreiheitsmaßnahmen darzustellen.

3. Weitere Möglichkeiten zur Messung der Barrierefreiheit

Dieser Entwurf untersucht auch Messmethoden, die über herkömmliche Bestanden/Nicht bestanden-Tests hinausgehen. Dazu können Rubriken, gleitende Skalen, die Erledigung von Aufgaben und gegebenenfalls Nutzerforschung mit Menschen mit Behinderungen gehören. Dies könnte insbesondere für komplexe Drupal-Anwendungen relevant sein, bei denen die Barrierefreiheit nicht immer durch die Überprüfung isolierter HTML-Elemente genau dargestellt werden kann.

4. Mehr Flexibilität bei technologischen Veränderungen

Eines der erklärten Ziele von WCAG 3 ist eine einfachere Pflege und Erweiterbarkeit. Anstatt einen Standard zu schaffen, dessen Aktualisierung mit technologischen Veränderungen immer schwieriger wird, ist der Entwurf so konzipiert, dass er im Laufe der Zeit neue Methoden, Anforderungen und Richtlinien berücksichtigen kann.

Warum ist WCAG 3.0 notwendig?

WCAG 2.1 und seine späteren Überarbeitungen sind nach wie vor etablierte Standards. Tatsächlich empfiehlt das W3C derzeit die Verwendung der neuesten WCAG-2-Version, wobei WCAG 2.2 neun neue Erfolgskriterien hinzufügt und gleichzeitig die Abwärtskompatibilität gewährleistet. 

Warum also WCAG 3.0 einführen?

1. Digitale Erlebnisse sind komplexer geworden

Websites sind längst keine einfachen Sammlungen von Seiten mehr. Sie umfassen interaktive Anwendungen, Personalisierung, dynamische Oberflächen, Videos, KI-gestützte Funktionen und immer komplexere Nutzerpfade. Leitlinien zur Barrierefreiheit müssen diesen Erfahrungen Rechnung tragen.

2. Das Bestehen einzelner Prüfungen bedeutet nicht immer, dass ein Erlebnis barrierefrei ist

Automatisierte Tests sind nützlich, aber bei der Barrierefreiheit geht es letztendlich darum, ob Menschen ein digitales Produkt effektiv nutzen können. Eine Website kann zwar korrekt beschriftete Schaltflächen haben und dennoch einen Verarbeitungsprozess verwirrend gestalten. Der Fokus von WCAG 3.0 auf Aufgaben und Ergebnisse könnte helfen, diese Lücke zu schließen. 

Unsere eigene branchenspezifischen Drupal-Auditdaten zeigen diese Lücke in der Praxis. In mehreren Branchen liegen die WCAG-AA-Fehlerquoten deutlich über 70 %, oft auf Seiten, die einzelne automatisierte Prüfungen bestehen.

3. Kognitive Barrierefreiheit benötigt mehr Aufmerksamkeit

Klare Sprache, vorhersehbare Navigation, verständliche Anweisungen und eine effektive Fehlerbehandlung können die Interaktion der Nutzer mit digitalen Diensten erheblich beeinflussen. Der aktuelle Entwurf räumt diesen Bereichen mehr Gewicht ein.

4. Standards müssen mit der Technologie Schritt halten

Neue Schnittstellen und Geräte werfen Fragen zur Barrierefreiheit auf, für deren Lösung ältere Standards nicht konzipiert waren. WCAG 3.0 soll im Zuge der Weiterentwicklung dieser Technologien leichter zu pflegen sein.

Wie man sich auf WCAG 3.0 vorbereitet

Die WCAG 3.0-Richtlinien befinden sich noch in der Entwicklung, daher gibt es keinen Grund, eine Website aufgrund von Anforderungen, die sich noch ändern können, neu zu gestalten. Der bessere Ansatz besteht darin, die bereits bestehenden Barrierefreiheitsmaßnahmen zu stärken und Lücken zu schließen, deren Behebung später schwieriger werden könnte.

1. Beginnen Sie mit WCAG 2.2

Wenn Ihre Website noch den WCAG 2.1 AA-Richtlinien entspricht, sind die WCAG 2.2 heute die geeignetere Grundlage, auf die Sie hinarbeiten sollten. Sie baut auf WCAG 2.1 auf und fügt Anforderungen für Bereiche wie Fokus-Sichtbarkeit, Zielgröße, barrierefreie Authentifizierung und redundante Eingabe hinzu, die alle in der offiziellen W3C-Spezifikation. 

Falls sich Ihre Barrierefreiheitsrichtlinie oder Ihre Entwicklungsstandards noch auf den WCAG 2.1 AA-Standard beziehen, überprüfen Sie diese anhand der neueren Anforderungen, die seitdem eingeführt wurden.

2. Blicken Sie über einzelne Seiten hinaus

Barrierefreiheitsprobleme entstehen oft durch gemeinsam genutzte Elemente und nicht durch einzelne Seiten. Eine Vorlage, Komponente oder ein Formularmuster mit einem Barrierefreiheitsproblem kann große Teile einer Website beeinträchtigen. 

Eine gründliche Prüfung sollte daher folgende Bereiche untersuchen: Vorlagen und wiederverwendbare Komponenten, Navigation und Formulare, Inhaltsstrukturen, benutzerdefinierte und von Drittanbietern stammende Funktionen sowie Designs und Module. Dies verschafft den Teams einen klareren Überblick darüber, wo Barrierefreiheitsprobleme ihren Ursprung haben und welche Korrekturen die größte Wirkung erzielen können.

3. Testen Sie, wie Nutzer die Website tatsächlich nutzen

Automatisierte Tests sind nützlich, um technische Probleme zu identifizieren, können jedoch nicht aufzeigen, ob Nutzer wichtige Aufgaben ohne Schwierigkeiten ausführen können.

Testen Sie typische Nutzerabläufe wie das Auffinden von Informationen, das Absenden eines Formulars, das Erstellen eines Kontos oder den Zugriff auf einen Dienst. Beziehen Sie gegebenenfalls Tests ausschließlich mit der Tastatur, Screenreadern und anderen assistiven Technologien ein.

Diese Art von Tests gewinnt zunehmend an Bedeutung, da Leitlinien zur Barrierefreiheit den Schwerpunkt stärker auf die Benutzererfahrung und die Ergebnisse legen.

4. Barrierefreiheit in den Entwicklungsprozess integrieren

Barrierefreiheit sollte nicht erst mit einem Audit beginnen, nachdem eine Website online gegangen ist. Sie sollte bereits bei der Erstellung neuer Komponenten, Funktionen und Inhalte berücksichtigt werden.

Für Entwicklungsteams bedeutet dies, Barrierefreiheitsprüfungen in folgende Bereiche einzubeziehen:

• Design- und Komponentenprüfungen
• Code-Prüfungen
• Workflows zur Veröffentlichung von Inhalten
• Tests vor der Veröffentlichung

Dadurch wird Barrierefreiheit zu einem Teil des Entwicklungszyklus und nicht zu einer separaten Maßnahme zur Einhaltung von Vorschriften

5. Testen Sie auch nach dem ersten Audit weiter

Eine Website kann nach einem Audit weniger barrierefrei werden, da sich die Website selbst ständig verändert. Neue Inhalte, Design-Aktualisierungen, Moduländerungen und kundenspezifische Entwicklungen können Probleme verursachen, die bei der ursprünglichen Bewertung noch nicht vorhanden waren.

Regelmäßige Tests und Überwachung können Teams dabei helfen, diese Änderungen frühzeitig zu erkennen, wiederkehrende Probleme zu verfolgen und die Fortschritte hinsichtlich WCAG 2.2 aufrechtzuerhalten, während WCAG 3.0 weiter Gestalt annimmt.

Machen Sie Ihre Website WCAG-konform

Es gibt noch kein bestätigtes Veröffentlichungsdatum für WCAG 3.0, und Organisationen sollten nicht auf den endgültigen Standard warten, um Barrierefreiheitslücken zu schließen. 

Für die meisten Teams besteht der einzige Weg darin, auf WCAG 2.2 hinzuarbeiten, die Barrierefreiheit auf der gesamten Website zu testen, wichtige Nutzerpfade zu bewerten und die Barrierefreiheit zu einem festen Bestandteil der laufenden Entwicklung und Wartung zu machen. 

Die Web Content Accessibility Guidelines (WCAG) werden sich weiterentwickeln, doch das Ziel bleibt dasselbe: Websites zu erstellen, die für alle funktionieren. Wenn Sie eine Drupal-Website verwalten, kann DrupalFit Ihnen helfen, den aktuellen Stand Ihrer Website zu ermitteln. 

Geben Sie die URL Ihrer Website ein, führen Sie ein Audit durch und überprüfen Sie den Abschnitt „Barrierefreiheit“, um Fehler und Warnungen zur Barrierefreiheit auf Ihren Seiten zu erkennen. Sie können Ihre Website außerdem anhand der WCAG-Stufen A, AA oder AAA bewerten und die Ergebnisse nutzen, um die Lücken zu schließen.

Prüfen Sie Ihre Drupal-Website mit DrupalFit!

Häufig gestellte Fragen

Ist WCAG 3.0 bereits veröffentlicht?

Nein. Es handelt sich noch um einen W3C-Arbeitsentwurf, der zuletzt im März 2026 aktualisiert wurde und für den noch kein Veröffentlichungsdatum feststeht.

Ist WCAG 2.1 AA eine gesetzliche Anforderung?

Das hängt von Ihrer Rechtsordnung und Ihrer Branche ab, aber die meisten aktuellen Vorschriften, darunter das ADA und der Europäische Barrierefreiheitsakt, verweisen ausdrücklich auf WCAG 2.1 AA oder WCAG 2.2.

Welche Version der WCAG sollte ich verwenden, 2.1 oder 2.2?

WCAG 2.2, da sie alle Anforderungen von 2.1 sowie neun zusätzliche Erfolgskriterien enthält. Es gibt keinen Grund, speziell auf die ältere Version abzustimmen.

Wie viele Erfolgskriterien umfasst WCAG 2.2?

Insgesamt 87, einschließlich der neun neuen, die zusätzlich zu WCAG 2.1 hinzugefügt wurden.