On 3 March 2026 (W3C Accessibility Guidelines 3.0, Working Draft 03/03/2026), the W3C published a new Working Draft of the W3C Accessibility Guidelines 3.0. Since then, one question keeps reaching us: do ongoing BFSG projects now need replanning? The evidence-based answer is no. WCAG 3 is a working draft, not a standard. The W3C states in the document itself that several years of work (W3C Accessibility Guidelines 3.0) remain before completion, and the Web Accessibility Initiative makes clear that WCAG 3 will not supersede WCAG 2 (W3C Web Accessibility Initiative). For the legal situation in Germany, the draft changes nothing: what counts is the harmonized European standard EN 301 549 (ETSI EN 301 549), not a W3C draft. This article places the status in context without hype and derives what product and engineering teams should actually do today.
Key takeaways
- On 3 March 2026 (W3C Accessibility Guidelines 3.0) the W3C published a Working Draft of WCAG 3.0, the earliest stage of its process. Candidate Recommendation and Proposed Recommendation are still ahead.
- Every section carries one of five maturity levels (W3C WCAG 3.0 Explainer) from Placeholder to Mature. Most of the material sits at Developing, including the conformance chapter and its open questions.
- Instead of success criteria at A, AA and AAA, the draft uses 12 guidelines (W3C Accessibility Guidelines 3.0), normative Requirements, process-based Assertions and informative Methods; Bronze, Silver and Gold are merely being explored.
- WCAG 3 does not retire WCAG 2: after a future release the 2.x versions stay in force for at least several years, and content meeting Level A and AA should already satisfy most of the coming baseline (W3C Accessibility Guidelines 3.0).
- For Germany the harmonised standard EN 301 549 applies through the BFSG, not a W3C draft. The date worth tracking is version V4.1.1 (ETSI EN 301 549), which lifts the web requirements to WCAG 2.2 Level AA.
- Useful work today: reach WCAG 2.2 Level AA, log tests with assistive technology as a head start on Assertions, and review the draft twice a year. A WCAG 3 certification has no basis while the conformance model is unfinished.
What Was Actually Published on 3 March 2026
A Working Draft is the earliest public stage in the W3C standardization process. It exists to collect feedback, not to be implemented. The document says so with unusual clarity: it is inappropriate to cite the draft as anything other than work in progress (W3C Accessibility Guidelines 3.0). By comparison, the WCAG 2.2 in force today completed the entire process and were adopted as a W3C Recommendation on 5 October 2023 (W3C Web Accessibility Initiative). Between Working Draft and Recommendation, the W3C process still holds the stages Candidate Recommendation and Proposed Recommendation. WCAG 3 has reached none of them.
That said, the draft is not nothing. It organizes its requirements into 12 guidelines (W3C Accessibility Guidelines 3.0) with titles such as Images and media, Text and wording, Interactive components and Error handling. The volume of fully drafted material has grown noticeably compared with earlier drafts, and part of the content has reached Developing maturity (W3C Web Accessibility Initiative). It is precisely this growth that the market misreads as "WCAG 3 is arriving now". Progress within a draft is something different from binding force.
Working Draft means: deliberately unfinished
While this draft has moved closer towards completion, it still has several years of work.
Reading the Five Maturity Levels Correctly
WCAG 3 introduces a feature the WCAG 2 never had: every section carries a visible maturity level. The Explainer defines five stages (W3C WCAG 3.0 Explainer) from Placeholder to Mature. This makes transparent how dependable an individual section is. That is not a detail for standards enthusiasts but the single most useful tool for judging the draft without hype: the maturity level answers whether a section can serve as a planning basis at all.
| Maturity level | What the W3C means by it | Implication for your project |
|---|---|---|
| Placeholder | The content is temporary and will be replaced entirely | Do not read as a requirement |
| Exploratory | Not refined, the direction is still being explored | No planning basis |
| Developing | Roughly agreed, high-level concerns still open | Observe, do not implement |
| Refining | Consensus reached, ready for wide review | Piloting conceivable |
| Mature | Believed by the working group to be ready for recommendation | Dependable for planning |
A look at the March 2026 draft is sobering for anyone expecting urgency: the bulk of the published material sits at Developing (W3C Accessibility Guidelines 3.0) maturity, the third of five stages. According to the Explainer, Developing means that what a section needs to achieve has been roughly agreed, but that not all high-level concerns have been settled (W3C WCAG 3.0 Explainer). It becomes even clearer with the conformance chapter, the very part that defines when something counts as conformant: it too carries Developing maturity, and the model is explicitly flagged with open questions (W3C Accessibility Guidelines 3.0).
The decisive point
Requirements, Assertions and Methods: the New Structure
The most striking change compared with WCAG 2 is structural. The familiar system of success criteria at levels A, AA and AAA gives way to a layered architecture. In the March 2026 version, the previously used term outcomes was replaced by requirements (W3C Accessibility Guidelines 3.0), which shows the direction: away from abstract goal statements, towards more concrete requirements. Four building blocks carry the draft.
Guidelines (normative)
User-centred outcome statements in plain language. They describe what people must be able to achieve and replace the four POUR principles as the top structural layer. The draft currently lists 12 of them.
Requirements (normative)
The technically testable requirements, split into core requirements for the baseline level and supplemental requirements for higher levels. They take the place of the WCAG 2 success criteria.
Assertions (normative)
Documented statements about processes carried out, such as usability testing with disabled people or testing with assistive technology. They capture work an external tester cannot verify from the code.
Methods (informative)
Techniques, examples and test sets for the requirements, technology-specific or technology-agnostic. They are guidance, not obligation, and roughly correspond to today's WCAG techniques.
For the conformance model, the working group is exploring levels that might provisionally be called Bronze, Silver and Gold (W3C WCAG 3.0 Explainer). Bronze is intended to consist of the core requirements, with higher levels drawing in supplemental requirements and assertions. The word "might" should be taken literally here: this is an exploratory status, not a decision. Anyone looking to plan dependably will find no solid basis in this chapter at present.
The one idea worth adopting today
Why WCAG 3 Does Not Replace WCAG 2
This is the most persistent misconception. The name suggests a replacement of the kind that happened from WCAG 2.0 to 2.1 and 2.2. The W3C explicitly contradicts that reading. The draft itself states that WCAG 3 is a successor to WCAG 2.2 but does not deprecate WCAG 2 (W3C Accessibility Guidelines 3.0). The Web Accessibility Initiative is even more concrete: WCAG 3 will not supersede WCAG 2, and WCAG 2 will not be deprecated for at least several years after WCAG 3 is finalized (W3C Web Accessibility Initiative).
- No replacement: WCAG 3 is a successor to WCAG 2.2 but does not deprecate WCAG 2 (W3C Accessibility Guidelines 3.0).
- No deprecation after completion: WCAG 2 remains valid for at least several years after a WCAG 3 publication (W3C Web Accessibility Initiative).
- Coverage commitment: WCAG 3 is not to be published until it covers at least as much as WCAG 2.2 (W3C WCAG 3.0 Explainer).
- Substantial head start: content meeting WCAG 2.2 Level A and AA is expected to meet most of the future minimum level (W3C Accessibility Guidelines 3.0).
- Similar needs: the core requirements are intended to cover a similar, though not identical, set of needs as WCAG 2.2 Level AA (W3C WCAG 3.0 Explainer).
The fourth point deserves emphasis because it dismantles the entire urgency narrative. The W3C writes that content conforming to WCAG 2.2 Level A and Level AA is expected to meet most of the minimum conformance level of the new standard, and that because WCAG 3 includes additional tests and different scoring mechanics, additional work will be needed (W3C Accessibility Guidelines 3.0). Translated: clean WCAG 2.2 AA work is the best conceivable preparation for WCAG 3. Not a detour, but the direct route. On top of that, WCAG 2.2 is now also published as ISO/IEC 40500:2025 (W3C Web Accessibility Initiative), anchoring it internationally more firmly than before. Which nine success criteria 2.2 adds over 2.1 is covered in our article on the new WCAG 2.2 success criteria.
WCAG 3 will not supersede WCAG 2, and WCAG 2 will not be deprecated for at least several years after WCAG 3 is finalized.
Authoritative for Germany: EN 301 549
Even if WCAG 3 were finished tomorrow, that would initially change nothing about the German legal situation. The BFSG does not reference W3C documents but the recognized rules of technology, made concrete by the harmonized European standard EN 301 549 (ETSI EN 301 549). This standard carries a presumption of conformity as soon as it is cited in the Official Journal of the EU for Directive (EU) 2019/882. A W3C draft simply has no place in this chain. How the layers interlock is shown in detail in our article on EN 301 549 as the standard behind the BFSG.
| Layer | Document | Status in 2026 | Binding for you? |
|---|---|---|---|
| EU law | Directive (EU) 2019/882 (EAA) | in force | indirectly, via national law |
| National law | BFSG | applicable since 28 June 2025 | included |
| Harmonized standard | EN 301 549 V3.2.1 | in force, V4.1.1 in preparation | yes, via presumption of conformity |
| Technical benchmark | WCAG 2.1 AA, in practice 2.2 AA | W3C Recommendation | yes, via the standard |
| W3C draft | WCAG 3.0 Working Draft | mostly Developing maturity | not included |
The only movement that matters for the legal situation in the foreseeable future is the evolution of the standard itself: the planned version V4.1.1 (ETSI EN 301 549) raises the web requirements to WCAG 2.2 Level AA. That is the date decision-makers should watch, not the roadmap of a W3C draft. Confusing the two leads to investment in the wrong place. Outside the web, too, the standard remains the benchmark, for instance for self-service terminals and vending machines, whose obligations stem from a dedicated chapter of EN 301 549.
How to spot WCAG 3 urgency used as a sales argument
What Teams Should Sensibly Do Today
The finding implies no standstill but a clear list of priorities. The work that has an effect today is the same as before 3 March 2026 – except that it is now additionally clear that it also pays into a future standard.
- Reach WCAG 2.2 Level AA properly. This is the legally relevant benchmark and, according to the W3C, at the same time most of the future minimum level (W3C Accessibility Guidelines 3.0). A structured WCAG 2.2 audit provides the baseline assessment.
- Anticipate assertions thinking. Build process documentation: who tested when with which assistive technology, which disabled people were involved, which decisions were made and why. This strengthens the accessibility statement already today.
- No switch to unfinished requirements. As long as the conformance chapter sits at Developing maturity (W3C Accessibility Guidelines 3.0), any alignment with it is premature and creates rework.
- Keep the architecture connectable. Semantic HTML, clean focus management and testable components are valuable under any conceivable version of WCAG 3 because they are technology-independent.
- Track the standards roadmap, not the draft roadmap. What matters is when EN 301 549 V4.1.1 is cited in the Official Journal (ETSI EN 301 549), not when a W3C draft is updated.
- Catch regressions early. Accessibility decays with every release; ongoing BFSG monitoring keeps the achieved level stable.
This list is deliberately unspectacular. That is the point: the WCAG 3 draft does not change the task list of a BFSG project. It confirms it. In our projects we regularly see that by far the largest share of open items falls into a few recurring patterns – missing text alternatives, insufficient contrast, components that cannot be operated by keyboard and forms without associated labels (project experience). Not one of these patterns is eased by WCAG 3; all of them are solvable under WCAG 2.2 AA today.
The one real change in working mode
Build for Continuity Instead of Replanning
The evidence-based answer to the opening question is therefore: ongoing BFSG projects do not need replanning because of the draft of 3 March 2026. They should be continued, because the only benchmark that is legally authoritative today remains EN 301 549 with WCAG 2.1, in practice 2.2, Level AA (ETSI EN 301 549). The draft is an important technical document and deserves attention from people who contribute to standards. It is not a reason to tear open a roadmap.
Our position on this is unexcited: we build against the standard that is legally authoritative today and keep projects connectable to coming standards through clean architecture. Concretely, that means accessible web development with semantic markup and testable components, a documented claim against WCAG 2.2 AA, and an accessibility statement that reflects the actual state rather than an aspiration. Teams that consider accessibility from the outset, as described in our article on accessibility by design, benefit twice at every change of standard, because the substance holds and only the testing mechanics change.
The same applies to the adjacent building blocks of a digital offering. Accessible PDF documents follow a dedicated chapter of the standard, accessible authentication is one of the nine 2.2 criteria, and where effort and benefit diverge, it is worth looking at the disproportionate burden under Section 17 BFSG. Training also pays into this continuity: a team that understands why a criterion exists will implement it correctly even when the numbering changes. And anyone who has once derived the BFSG requirements for their offering cleanly does not have to start that derivation again at a change of standard, only extend it.
Practical tip for your next roadmap round