Am 3. März 2026 (W3C Accessibility Guidelines 3.0, Working Draft 03.03.2026) hat das W3C einen neuen Working Draft der W3C Accessibility Guidelines 3.0 veröffentlicht. Seitdem erreicht uns regelmäßig dieselbe Frage: Müssen laufende BFSG-Projekte jetzt umgeplant werden? Die belegbare Antwort lautet nein. WCAG 3 ist ein Arbeitsentwurf, kein Standard. Das W3C schreibt im Dokument selbst, dass vor der Fertigstellung noch mehrere Jahre Arbeit (W3C Accessibility Guidelines 3.0) liegen, und die Web Accessibility Initiative stellt klar, dass WCAG 3 die WCAG 2 nicht ablösen wird (W3C Web Accessibility Initiative). Für die Rechtslage in Deutschland ändert der Entwurf nichts: Maßgeblich ist die harmonisierte europäische Norm EN 301 549 (ETSI EN 301 549), nicht ein Entwurf des W3C. Dieser Beitrag ordnet den Stand sachlich ein und leitet ab, was Produkt- und Entwicklungsteams heute tatsächlich tun sollten.
Das Wichtigste in Kürze
- Am 3. März 2026 (W3C Accessibility Guidelines 3.0) erschien ein Working Draft der WCAG 3.0, die früheste Stufe im W3C-Prozess. Candidate Recommendation und Proposed Recommendation stehen noch aus.
- Jeder Abschnitt trägt einen von fünf Reifegraden (W3C WCAG 3.0 Explainer) von Placeholder bis Mature. Der Großteil des Materials steht auf Developing, auch das Conformance-Kapitel mit seinen offenen Fragen.
- Statt Erfolgskriterien mit A, AA und AAA gliedert der Entwurf in 12 Guidelines (W3C Accessibility Guidelines 3.0), normative Requirements, prozessbezogene Assertions und informative Methods; Bronze, Silber und Gold werden nur erkundet.
- WCAG 3 löst die WCAG 2 nicht ab: Nach einer Fertigstellung bleiben sie mindestens mehrere Jahre in Kraft, und Inhalte auf Level A und AA sollen den Großteil der künftigen Mindeststufe bereits erfüllen (W3C Accessibility Guidelines 3.0).
- Für Deutschland zählt die harmonisierte Norm EN 301 549 über das BFSG, nicht ein W3C-Entwurf. Der Termin, den Verantwortliche verfolgen sollten, ist die Fassung V4.1.1 (ETSI EN 301 549) mit WCAG 2.2 Level AA.
- Sinnvoll sind heute WCAG 2.2 Level AA, protokollierte Tests mit assistiver Technik als Vorgriff auf Assertions und ein halbjährlicher Blick auf den Entwurf. Eine WCAG-3-Zertifizierung hat mangels Konformitätsmodell keine Grundlage.
Was am 3. März 2026 veröffentlicht wurde
Ein Working Draft ist die früheste öffentliche Stufe im Standardisierungsprozess des W3C. Er existiert, um Rückmeldungen einzusammeln, nicht um umgesetzt zu werden. Das Dokument formuliert das ungewöhnlich deutlich: Es sei unangemessen, den Entwurf als etwas anderes zu zitieren denn als laufende Arbeit (W3C Accessibility Guidelines 3.0). Zum Vergleich: Die heute geltenden WCAG 2.2 haben den kompletten Prozess durchlaufen und wurden am 5. Oktober 2023 (W3C Web Accessibility Initiative) als W3C Recommendation verabschiedet. Zwischen Working Draft und Recommendation liegen im W3C-Prozess noch die Stufen Candidate Recommendation und Proposed Recommendation. WCAG 3 hat keine davon erreicht.
Inhaltlich ist der Entwurf trotzdem kein Nichts. Er gliedert die Anforderungen in 12 Guidelines (W3C Accessibility Guidelines 3.0) mit Titeln wie Images and media, Text and wording, Interactive components oder Error handling. Die Menge an ausformuliertem Material ist gegenüber den Vorgängerentwürfen spürbar gewachsen, und ein Teil der Inhalte hat den Reifegrad Developing erreicht (W3C Web Accessibility Initiative). Genau diese Wachstumsbewegung ist es, die im Markt als „WCAG 3 kommt jetzt" fehlgedeutet wird. Fortschritt in einem Entwurf ist etwas anderes als Verbindlichkeit.
Working Draft heißt: bewusst unfertig
Auch wenn dieser Entwurf der Fertigstellung nähergekommen ist, liegen noch mehrere Jahre Arbeit vor ihm.
Die fünf Reifegrade richtig lesen
WCAG 3 bringt eine Eigenheit mit, die es in den WCAG 2 so nicht gab: Jeder Abschnitt trägt einen sichtbaren Reifegrad. Der Explainer definiert fünf Stufen (W3C WCAG 3.0 Explainer) von Placeholder bis Mature. Damit macht die Arbeitsgruppe transparent, wie belastbar ein einzelner Abschnitt ist. Das ist kein Detail für Normfreunde, sondern das wichtigste Werkzeug, um den Entwurf ohne Hype zu bewerten: Der Reifegrad beantwortet die Frage, ob ein Abschnitt überhaupt eine Planungsgrundlage sein kann.
| Reifegrad | Was das W3C damit aussagt | Praxisfolge für Ihr Projekt |
|---|---|---|
| Placeholder | Der Inhalt ist temporär und wird vollständig ersetzt | Nicht als Anforderung lesen |
| Exploratory | Nicht ausgearbeitet, die Richtung wird noch gesucht | Keine Planungsgrundlage |
| Developing | Grob abgestimmt, Grundsatzfragen noch offen | Beobachten, nicht umsetzen |
| Refining | Konsens erreicht, bereit für breites Review | Pilotierung denkbar |
| Mature | Aus Sicht der Arbeitsgruppe empfehlungsreif | Belastbar planbar |
Der Blick in den Entwurf vom März 2026 ist ernüchternd für alle, die Dringlichkeit erwarten: Der Großteil des veröffentlichten Materials steht im Reifegrad Developing (W3C Accessibility Guidelines 3.0), also auf der dritten von fünf Stufen. Developing bedeutet laut Explainer, dass grob abgestimmt ist, was der Abschnitt leisten soll, dass aber nicht alle übergeordneten Fragen geklärt sind (W3C WCAG 3.0 Explainer). Noch deutlicher wird es beim Conformance-Kapitel, also genau dem Teil, der festlegt, wann etwas als konform gilt: Auch er trägt den Reifegrad Developing, und das Modell ist ausdrücklich mit offenen Fragen versehen (W3C Accessibility Guidelines 3.0).
Der entscheidende Punkt
Requirements, Assertions und Methods: die neue Struktur
Die auffälligste Änderung gegenüber den WCAG 2 ist strukturell. Die vertraute Systematik aus Erfolgskriterien mit den Stufen A, AA und AAA weicht einem mehrschichtigen Aufbau. In der Fassung vom März 2026 wurde der zuvor genutzte Begriff Outcomes durch Requirements ersetzt (W3C Accessibility Guidelines 3.0), was die Richtung zeigt: weg von abstrakten Zielbeschreibungen, hin zu konkreteren Anforderungen. Vier Bausteine tragen den Entwurf.
Guidelines (normativ)
Nutzerzentrierte Ergebnisaussagen in einfacher Sprache. Sie beschreiben, was Menschen erreichen können müssen, und ersetzen die vier POUR-Prinzipien als oberste Gliederungsebene. Der Entwurf führt derzeit 12 davon.
Requirements (normativ)
Die technisch prüfbaren Anforderungen, unterteilt in Core Requirements für die Mindeststufe und Supplemental Requirements für höhere Stufen. Sie treten an die Stelle der Erfolgskriterien der WCAG 2.
Assertions (normativ)
Belegte Aussagen über durchgeführte Prozesse, etwa Usability-Tests mit Betroffenen oder Prüfungen mit assistiver Technik. Sie erfassen Arbeit, die ein externer Prüfer am Code nicht verifizieren kann.
Methods (informativ)
Techniken, Beispiele und Testsätze zu den Anforderungen, technologiespezifisch oder technologieagnostisch. Sie sind Hilfestellung, nicht Pflicht, und entsprechen grob den heutigen WCAG-Techniques.
Für das Konformitätsmodell prüft die Arbeitsgruppe Stufen, die vorläufig Bronze, Silber und Gold (W3C WCAG 3.0 Explainer) heißen könnten. Bronze soll dabei aus den Core Requirements bestehen, höhere Stufen sollen Supplemental Requirements und Assertions einbeziehen. Das Wort „könnten" ist hier wörtlich zu nehmen: Es handelt sich um einen Explorationsstand, nicht um eine Festlegung. Wer belastbar planen will, findet in diesem Kapitel derzeit keine tragfähige Grundlage.
Die eine Idee, die sich heute schon lohnt
Warum WCAG 3 die WCAG 2 nicht ersetzt
Hier liegt das hartnäckigste Missverständnis. Der Name legt eine Ablösung nahe, wie sie von WCAG 2.0 zu 2.1 und 2.2 stattfand. Das W3C widerspricht dieser Lesart ausdrücklich. Im Entwurf selbst steht, dass WCAG 3 zwar ein Nachfolger der WCAG 2.2 ist, die WCAG 2 aber nicht abkündigt (W3C Accessibility Guidelines 3.0). Die Web Accessibility Initiative wird noch konkreter: WCAG 3 werde die WCAG 2 nicht verdrängen, und die WCAG 2 würden auch nach einer Fertigstellung von WCAG 3 für mindestens mehrere Jahre nicht abgekündigt (W3C Web Accessibility Initiative).
- Kein Ersatz: WCAG 3 ist Nachfolger der WCAG 2.2, kündigt die WCAG 2 aber nicht ab (W3C Accessibility Guidelines 3.0).
- Keine Abkündigung nach Fertigstellung: Die WCAG 2 bleiben nach einer WCAG-3-Veröffentlichung für mindestens mehrere Jahre gültig (W3C Web Accessibility Initiative).
- Deckungszusage: WCAG 3 soll erst veröffentlicht werden, wenn es mindestens so viel abdeckt wie die WCAG 2.2 (W3C WCAG 3.0 Explainer).
- Weitgehende Vorleistung: Inhalte, die WCAG 2.2 Level A und AA erfüllen, sollen den Großteil der künftigen Mindeststufe bereits erfüllen (W3C Accessibility Guidelines 3.0).
- Ähnlicher Bedarf: Die Core Requirements sollen einen ähnlichen, wenn auch nicht identischen Satz an Bedürfnissen abdecken wie WCAG 2.2 Level AA (W3C WCAG 3.0 Explainer).
Der vierte Punkt verdient Betonung, weil er das gesamte Dringlichkeitsnarrativ entkräftet. Das W3C schreibt, dass Inhalte mit WCAG-2.2-Konformität auf Level A und AA voraussichtlich den Großteil der Mindeststufe des neuen Standards erfüllen; wegen zusätzlicher Tests und anderer Bewertungsmechanik bleibe zusätzliche Arbeit nötig (W3C Accessibility Guidelines 3.0). Übersetzt heißt das: Saubere WCAG-2.2-AA-Arbeit ist die beste denkbare Vorbereitung auf WCAG 3. Nicht ein Umweg, sondern der direkte Weg. Hinzu kommt, dass die WCAG 2.2 inzwischen auch als ISO/IEC 40500:2025 (W3C Web Accessibility Initiative) geführt werden, also international noch fester verankert sind als zuvor. Welche neun Erfolgskriterien die 2.2 gegenüber der 2.1 ergänzt, haben wir in unserem Beitrag zu den neuen WCAG-2.2-Erfolgskriterien aufbereitet.
WCAG 3 wird die WCAG 2 nicht verdrängen, und die WCAG 2 werden nach einer Fertigstellung von WCAG 3 für mindestens mehrere Jahre nicht abgekündigt.
Für Deutschland maßgeblich: die EN 301 549
Selbst wenn WCAG 3 morgen fertig wäre, änderte das an der deutschen Rechtslage zunächst nichts. Das BFSG verweist nicht auf W3C-Dokumente, sondern auf die anerkannten Regeln der Technik, konkretisiert durch die harmonisierte europäische Norm EN 301 549 (ETSI EN 301 549). Diese Norm entfaltet Vermutungswirkung, sobald sie im Amtsblatt der EU zur Richtlinie (EU) 2019/882 zitiert ist. Ein W3C-Entwurf hat in dieser Kette schlicht keinen Platz. Wie die Ebenen ineinandergreifen, zeigt unser Beitrag zur EN 301 549 als Norm hinter dem BFSG im Detail.
| Ebene | Dokument | Status 2026 | Für Sie verbindlich? |
|---|---|---|---|
| EU-Recht | Richtlinie (EU) 2019/882 (EAA) | in Kraft | mittelbar, über nationales Recht |
| Nationales Recht | BFSG | seit 28.06.2025 anwendbar | enthalten |
| Harmonisierte Norm | EN 301 549 V3.2.1 | in Kraft, V4.1.1 in Vorbereitung | ja, über Vermutungswirkung |
| Technischer Maßstab | WCAG 2.1 AA, praktisch 2.2 AA | W3C Recommendation | ja, über die Norm |
| W3C-Entwurf | WCAG 3.0 Working Draft | Reifegrad überwiegend Developing | nicht enthalten |
Die einzige Bewegung, die für die Rechtslage in absehbarer Zeit zählt, ist die Fortschreibung der Norm selbst: Die geplante Fassung V4.1.1 (ETSI EN 301 549) hebt die Web-Anforderungen auf WCAG 2.2 Level AA. Das ist der Termin, den Verantwortliche im Blick behalten sollten, nicht der Fahrplan eines W3C-Entwurfs. Beides zu verwechseln, führt zu Investitionen an der falschen Stelle. Auch außerhalb des Webs bleibt die Norm der Maßstab, etwa bei Selbstbedienungsterminals und Automaten, deren Pflichten aus einem eigenen Kapitel der EN 301 549 stammen.
Woran Sie WCAG-3-Dringlichkeit als Verkaufsargument erkennen
Was Teams heute sinnvoll tun
Aus dem Befund folgt kein Stillstand, sondern eine klare Prioritätenliste. Die Arbeit, die heute Wirkung entfaltet, ist dieselbe wie vor dem 3. März 2026 – nur dass jetzt zusätzlich klar ist, dass sie auch auf einen künftigen Standard einzahlt.
- WCAG 2.2 Level AA sauber erreichen. Das ist der rechtlich relevante Maßstab und laut W3C zugleich der Großteil der künftigen Mindeststufe (W3C Accessibility Guidelines 3.0). Ein strukturiertes WCAG-2.2-Audit liefert dafür die Bestandsaufnahme.
- Assertions-Denke vorwegnehmen. Prozessdokumentation aufbauen: Wer hat wann mit welcher assistiven Technik getestet, welche Betroffenen waren beteiligt, welche Entscheidungen wurden warum getroffen. Das stärkt schon heute die Barrierefreiheitserklärung.
- Keine Umstellung auf unfertige Requirements. Solange das Conformance-Kapitel im Reifegrad Developing steht (W3C Accessibility Guidelines 3.0), ist jede Ausrichtung darauf verfrüht und erzeugt Nacharbeit.
- Architektur anschlussfähig halten. Semantisches HTML, saubere Fokusverwaltung und testbare Komponenten sind unter jeder denkbaren Fassung von WCAG 3 wertvoll, weil sie technologieunabhängig sind.
- Den Normfahrplan verfolgen, nicht den Entwurfsfahrplan. Relevant ist, wann die EN 301 549 V4.1.1 im Amtsblatt zitiert wird (ETSI EN 301 549), nicht wann ein W3C-Entwurf aktualisiert wird.
- Regressionen früh erkennen. Barrierefreiheit verfällt mit jedem Release; laufendes BFSG-Monitoring hält den erreichten Stand stabil.
Diese Liste ist bewusst unspektakulär. Das ist die Pointe: Der WCAG-3-Entwurf verändert die Aufgabenliste eines BFSG-Projekts nicht. Er bestätigt sie. In unseren Projekten sehen wir regelmäßig, dass der weitaus größte Teil der offenen Punkte auf wenige wiederkehrende Muster entfällt – fehlende Textalternativen, unzureichende Kontraste, nicht tastaturbedienbare Komponenten und Formulare ohne verknüpfte Beschriftungen (Projekterfahrung). Kein einziges dieser Muster wird von WCAG 3 entschärft; alle sind schon unter WCAG 2.2 AA zu lösen.
Die einzige echte Änderung im Arbeitsmodus
Anschlussfähig bauen statt umplanen
Die belastbare Antwort auf die Eingangsfrage lautet also: Laufende BFSG-Projekte müssen wegen des Entwurfs vom 3. März 2026 nicht umgeplant werden. Sie sollten fortgesetzt werden, weil der einzige heute rechtlich maßgebliche Maßstab unverändert die EN 301 549 mit WCAG 2.1 beziehungsweise praktisch 2.2 Level AA ist (ETSI EN 301 549). Der Entwurf ist ein wichtiges Fachdokument und verdient Aufmerksamkeit von Menschen, die an Standards mitarbeiten. Er ist kein Grund, eine Roadmap aufzureißen.
Unsere Position dazu ist unaufgeregt: Wir bauen gegen die heute rechtlich maßgebliche Norm und halten Projekte durch saubere Architektur an kommende Standards anschlussfähig. Konkret heißt das barrierefreie Webentwicklung mit semantischem Markup und testbaren Komponenten, ein dokumentierter Nachweis gegen WCAG 2.2 AA und eine Barrierefreiheitserklärung, die den tatsächlichen Stand abbildet statt eine Wunschvorstellung. Wer Barrierefreiheit von Beginn an mitdenkt, wie im Beitrag zu Accessibility by Design beschrieben, profitiert bei jedem Standardwechsel doppelt, weil die Substanz stimmt und nur die Prüfmechanik wechselt.
Das gilt auch für die angrenzenden Bausteine eines digitalen Angebots. Barrierefreie PDF-Dokumente folgen einem eigenen Kapitel der Norm, barrierefreie Authentifizierung gehört zu den neun 2.2-Kriterien, und wo Aufwand und Nutzen auseinanderfallen, lohnt der Blick auf die unverhältnismäßige Belastung nach Paragraf 17 BFSG. Auch Schulungen zahlen auf diese Kontinuität ein: Ein Team, das versteht, warum ein Kriterium existiert, setzt es auch dann korrekt um, wenn sich die Nummerierung ändert. Und wer die BFSG-Anforderungen für sein Angebot einmal sauber hergeleitet hat, muss diese Herleitung bei einem Standardwechsel nicht neu beginnen, sondern nur fortschreiben.
Praxistipp für die nächste Roadmap-Runde