Since their introduction in 1999, the Web Content Accessibility Guidelines (WCAG) have shaped how we design and develop inclusive digital products. Released in 2008, the WCAG 2.x series introduced clear technical criteria evaluated through a binary model: a success criterion is either passed or failed. While this model provided legal clarity and auditability, its “all or nothing” nature often fails to reflect the nuances of real user experience (UX).
Over time, this gap between technical compliance and actual usability has become increasingly difficult to ignore. People interact with digital systems in complex, often non-linear ways: navigating multi-step processes, dynamic content, and interactive states. In these cases, checking whether an element meets a rule does not always answer the essential question: can someone actually use it?
WCAG 3.0 is still in draft form, but it is evolving — and it represents a fundamental rethinking of accessibility evaluation. Instead of asking whether a requirement has technically been met, it asks how well users with disabilities can complete meaningful tasks. The new outcome-oriented model introduces a flexible scoring system that prioritises usability over compliance, shifting the focus from the simple presence of features to the quality of access.
Draft status: ambitious, but still being refined
WCAG 3.0 was first introduced as a public working draft by the World Wide Web Consortium (W3C) Accessibility Guidelines Working Group in early 2021. The draft is still under active development and, according to some estimates, is not expected to reach W3C Recommendation status for several more years — perhaps even decades. This long timeline reflects both the complexity of the task and the ambition behind it:
WCAG 3.0 is not just an update. It is a paradigm shift.
Unlike WCAG 2.x, which focused primarily on web pages, WCAG 3.0 aims to cover a much broader ecosystem, including applications, tools, connected devices, and emerging interfaces such as voice control and augmented reality. The name also changes to W3C Accessibility Guidelines — although the WCAG acronym remains the same — signalling that accessibility is no longer a niche concern, but a baseline expectation across the digital world.
Importantly, WCAG 3.0 will not immediately replace WCAG 2.x. Both standards will coexist, and compliance with WCAG 2.2 will remain valid and necessary for some time, especially in legal and policy contexts.
This expansion is not only technical.
WCAG 3.0 reflects a deeper philosophical shift: accessibility is moving from a compliance model to an effectiveness model.
Rules alone cannot determine whether a system truly works for a specific person. That is why WCAG 3.0 is built around flexibility and future-readiness, aiming to support evolving technologies and real-world use over time. It formalises a principle that practitioners have understood for years:
Inclusive design is not about passing a test; it is about enabling people.
A new structure: from success criteria to outcomes and methods
The WCAG 2.x structure is based on four core principles — Perceivable, Operable, Understandable, and Robust (POUR) — and testable success criteria divided into three conformance levels: A, AA, and AAA. Although technically precise, these criteria often emphasise implementation rather than impact.
WCAG 3.0 reorients this structure around user needs and real outcomes. Its hierarchy is based on:
- Guidelines: High-level accessibility goals connected to specific user needs.
- Outcomes: Testable, user-centred statements, such as “Users have alternatives for time-based media.”
- Methods: Technology-specific or technology-agnostic techniques that help achieve outcomes, including code examples and testing instructions.
- How-to guides: Explanatory documentation with practical advice, user context, and design considerations.
This shift is more than organisational. It reflects a deeper commitment to aligning technical implementation with user experience. Outcomes speak the language of capability, defining what users should be able to do — not merely whether a technical feature exists.
Most importantly, outcomes are also where conformance evaluation begins. For example, imagine a checkout process on an e-commerce website. Under WCAG 2.x, if even one field in the checkout form is missing a label, the process may fail AA conformance entirely. Under WCAG 3.0, the same process could be evaluated across several outcomes — such as keyboard navigation, form labelling, focus management, and error handling — with each outcome receiving its own score. If most areas perform well but error messages are poor, the overall rating might be “Good” rather than “Excellent”, encouraging targeted improvements without dismissing the accessibility of the entire process.
From binary checks to scored outcomes
Instead of relying on “pass” or “fail” results, WCAG 3.0 introduces a scoring model that reflects how well accessibility is supported. This shift allows teams to recognise partial success and prioritise real-world improvements.
How does scoring work?
Each WCAG 3.0 outcome is evaluated through one or more atomic tests. These may include:
- Binary tests: Yes/no answers, such as whether every image has alternative text.
- Percentage-based tests: Evaluation based on coverage, such as what percentage of form fields have labels.
- Qualitative tests: Criteria-based assessments, such as how descriptive the alternative text is.
The results of these tests form a score for each outcome, often normalised on a 0–4 or 0–5 scale, with labels such as “Poor”, “Fair”, “Good”, and “Excellent”. These scores are later aggregated across functional categories — such as vision, mobility, cognition, and so on — and user processes.
This allows teams to measure progress, not just compliance. A product that improves from “Fair” to “Good” over time shows real evolution — a concept that does not exist in WCAG 2.x.
Critical errors: the balancing mechanism
To ensure that severity still matters, WCAG 3.0 introduces critical errors — high-impact accessibility failures that can override an otherwise positive score.
For example, let’s return to the checkout process. Under WCAG 2.x, one missing label can cause the entire process to fail. WCAG 3.0, however, evaluates multiple outcomes — such as form labelling, keyboard access, and error handling — each with its own score. Minor issues, such as unclear error messages or a missing label on an optional field, may reduce the rating from “Excellent” to “Good”, but they do not make the entire experience unusable.
But if a user cannot complete a core action — such as submitting a form, completing a purchase, or logging in — this is considered a critical error. These failures directly block task completion and significantly lower the overall score, regardless of how polished the rest of the experience may be.
By contrast, issues with non-essential features — such as uploading a profile photo or changing a theme colour — are considered lower impact and will not affect the evaluation as heavily.
Conformance levels: Bronze, Silver, Gold
Instead of dividing conformance into A, AA, and AAA levels, WCAG 3.0 proposes three different conformance levels:
- Bronze: The new minimum level. It is comparable to WCAG 2.2 AA, but based on scoring and foundational outcomes. The requirements are expected to be achievable through automated and guided manual testing.
- Silver: A higher standard requiring broader coverage, higher scores, and usability validation from people with disabilities.
- Gold: The highest level. It reflects exemplary accessibility and will likely require inclusive design processes, innovation, and broad user involvement.
Unlike WCAG 2.2, where AAA is often seen as aspirational and inconsistent, these levels are designed to encourage progress. They can also be applied in parts, meaning teams can declare conformance for a checkout process, mobile app, or specific feature, allowing for gradual improvement.
What should you do now?
Although WCAG 3.0 is still under development, its direction is clear. Still, it is important to recognise that the guidelines are not expected to be finalised for several years. Here is how teams can prepare:
- Continue aiming for WCAG 2.2 AA. It remains the strongest and most widely recognised standard.
- Familiarise yourself with the WCAG 3.0 drafts, especially the outcomes and scoring model.
- Start thinking in outcomes. Focus on what users need to accomplish, not just which features exist.
- Integrate accessibility into workflows. Move it earlier in the process. Do not test at the end — design and build with access in mind.
- Involve users with disabilities early and regularly.
These practices will not only make your product more inclusive; they will prepare your team to work successfully under WCAG 3.0.
Potential drawbacks
Although WCAG 3.0 is a bold step toward more holistic accessibility, several structural risks require early attention, especially for organisations that face regulation, scale design systems, or build sustainable accessibility practices. Importantly, many of these risks are connected: challenges in one area can reinforce problems in another.
Subjective evaluation
The move from binary “pass/fail” criteria to scored outcomes leaves room for subjective interpretation. Without standardised calibration, the same user process may receive different scores depending on the evaluator. This makes comparability and repeatability more difficult, especially in procurement or multi-vendor environments. A simple piece of alternative text might be rated as “sufficient” by one team and “unclear” by another.
Reduced conformance clarity
The same subjectivity raises a second concern: the erosion of clear conformance boundaries. Scoring replaces the binary clarity of “conforms” or “does not conform” with a more flexible but less defined result. This may complicate legal enforcement, contractual definitions, and audit reports. In practice, a product could receive a “Good” rating while still having critical usability gaps for certain users, creating a disconnect between the score and real access.
Legal and policy misalignment
When conformance clarity decreases, so does alignment with existing legal systems. Many current laws explicitly reference WCAG 2.x and its A, AA, and AAA levels, such as Section 508 of the U.S. Rehabilitation Act of 1973, the European Accessibility Act, and the UK Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018.
Until WCAG 3.0 is formally mapped to these standards, using it in regulated contexts may introduce risk. Teams working in healthcare, finance, or the public sector will likely need dual conformance strategies during the transition, increasing both cost and complexity.
The risk of minimally viable accessibility
Perhaps most concerning is that this ambiguity could create a “minimally viable accessibility” mindset. Scoring models risk encouraging the idea that “Bronze is good enough”, especially in deadline-driven environments. A team may stop prioritising improvements as soon as it reaches a passing level, even if meaningful barriers remain.
For example, a mobile app with strong keyboard support but no transcripts for audio content could still achieve a passing level, while leaving some users excluded.
Conclusion
WCAG 3.0 marks a new era of accessibility — one that better reflects the diversity and complexity of real users. By moving from checklists to scored outcomes, and from strict technical compliance to practical usability, it encourages teams to prioritise real impact over theoretical perfection.
As the saying goes, “It is not the score that matters. It is who can use the product.” Our own experience shows that teams can spend hours fixing minor colour contrast issues while missing broken keyboard navigation that prevents screen reader users from completing essential tasks. WCAG 3.0’s focus on outcomes reminds us that accessibility is ultimately about functionality and inclusion.
At the same time, WCAG 3.0’s proposed scoring models introduce new responsibilities. Without clear calibration, stronger enforcement models, and a cultural shift away from “good enough”, we risk losing the very clarity that made WCAG 2.x implementable and practical. The promise of flexibility only works if we use it to aim higher — not to stop earlier.
For teams across design, development, and product management, this shift is an opportunity to rethink what success means. Accessibility is not about ticking boxes; it is about enabling people.
By preparing now, acknowledging the risks, and focusing on user outcomes, we are not just getting ahead of WCAG 3.0 — we are building digital experiences that are genuinely usable, sustainable, and inclusive.
