Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors

Website projects · Accessibility standards

A supplier promises a “WCAG 3 compliant” website. Before you pay for that label, check what is a standard today, what is still a draft, and what your project will actually test.

Editorial note · Sources checked 4 October 2026

Imagine a redesign proposal that says: “We will deliver a fully WCAG 3 compliant website.” It sounds precise. It is not yet a useful acceptance criterion: WCAG 3 is still a Working Draft, not a finished W3C Recommendation.

What to do now: do not switch your accessibility target because of the September draft. Use the applicable published standard and legal requirements for your service, keep improving the real user journeys, and require a written test scope and findings from the supplier.

The September update changes the draft—not today’s standard

W3C’s 10 September 2026 WCAG 3 Working Draft is part of an active development process. The revised conformance approach is still under discussion. W3C’s updated introduction says parts remain exploratory or in development and may change substantially; WCAG 3 is not expected to become a completed standard for a few more years.

Current W3C RecommendationWCAG 2.2 is the published recommendation. W3C says the best way to prepare for WCAG 3 is to meet WCAG 2.2 now.
Developing workWCAG 3 is a Working Draft with sections at different maturity stages. W3C says it will not supersede WCAG 2, and WCAG 2 will not be deprecated for several years after WCAG 3 is finalised.

That distinction matters. A draft can help product teams anticipate future design questions, but it is not a stable pass/fail label to put in a contract. Start with the W3C’s WCAG 3 introduction, check its publication history, and treat the WCAG 2.2 Recommendation as the current W3C standard.

Website owner compares an accessibility project draft beside a laptop displaying an enquiry form
A buyer needs a clear project scope and test evidence—not a claim based on a changing draft.

Unpack the supplier claim before you accept it

Return to the fictional proposal. “WCAG 3 compliant” bundles together three different questions that should be answered separately.

First: which published criteria and level will be tested? Ask the supplier to name the standard version and conformance target in the agreement. If they are exploring a WCAG 3 draft feature, label it as exploratory work—not as a conformance result.

Second: what does the law require for this service? The European Accessibility Act has applied since 28 June 2025 to specified products and services, including e-commerce. It does not automatically put every business brochure site under the same obligations, and the directive includes exemptions such as micro-enterprises providing services. Scope depends on the service and national implementation, so get a qualified, jurisdiction-specific answer rather than inferring a legal duty from a W3C draft. See the EUR-Lex summary of the European Accessibility Act and Your Europe’s business guidance.

Third: what evidence will you receive? “We ran an accessibility scanner” does not tell you whether a keyboard user can submit the quote form, whether labels and errors make sense, or what remains unresolved. Ask which important routes are included, how findings will be recorded, who fixes them, and whether the fixes will be checked again. A tool report can be one input; it is not the whole acceptance test.

Turn a vague promise into a testable brief

For a new website, replace the floating label with a sentence that identifies the service, agreed target, key tasks and handover evidence. For example:

Sample acceptance wording

“Before handover, the supplier will test the agreed priority journeys—[list the specific journeys]—against [the named standard, version and conformance level selected for this project]. The supplier will provide a dated findings record, identify known exceptions and their impact, assign remediation responsibilities, and retest agreed fixes. Any exploratory WCAG 3 work will be reported separately from the conformance assessment.”

This is not a universal legal clause or a guarantee of compliance. It makes the work reviewable: the buyer can see what was examined, what was not, and what needs a decision. A strong website creation brief treats accessibility as part of the actual enquiry, booking or checkout path—not a certificate added after launch.

Keep improving the experience while the standard evolves

You do not need a WCAG 3 re-audit just because a new draft appeared. If you are commissioning work now, choose the applicable published target with the right advice, test the tasks that matter to customers, and record limitations honestly. If you already have an accessibility programme, continue it; revisit WCAG 3 when W3C publishes a stable transition path.

For a separate technical review, see what a technical SEO and website audit should make visible about a site’s practical risks. It should not be sold as a legal accessibility certification.

Frequently asked questions

Is WCAG 3 a final accessibility standard?

No. As of 4 October 2026, WCAG 3 is a W3C Working Draft. W3C says it remains incomplete, will change, and is not expected to become a finished standard for a few more years.

Should a website project target WCAG 3 now?

Not as a conformance target. W3C identifies WCAG 2.2 as the current recommendation and says meeting WCAG 2.2 is the best preparation for WCAG 3. Confirm the target required by your project and any applicable law.

Does the European Accessibility Act apply to every business website?

No single answer covers every site. The Act covers specified products and services, including e-commerce, and includes exemptions such as micro-enterprises providing services. Ask for a scope-specific answer under the national rules that apply to your business.

Planning a new website? Include accessible customer journeys in the brief, then define how the finished work will be reviewed.

Explore AI-assisted website creation or discuss your project scope.