The accessibility guidelines we’ve been using for more than a decade no longer fully address the needs of people with disabilities. A new version of Web Content Accessibility Guidelines, WCAG 3.0, is in development and is expected to be officially released later this decade.
Rubyroid Labs, experts in UX/UI design and audit services, closely follow the upcoming updates. In this article, we’ll explain why the old framework needed to be rethought, what changes W3C Accessibility Guidelines 3.0 will introduce, and how companies can start preparing their products in advance.
Contents
- Why it became necessary to update Accessibility Guidelines
- What will change in WCAG 3.0
- Will W3C accessibility guidelines 3.0 shape the work of designers, developers, and businesses?
- How to prepare for WCAG 3.0 compliance: 5 tips from Rubyroid Labs
- Conclusion: why start preparing for WCAG 3.0 now
Why it became necessary to update Accessibility Guidelines
Since the first Web Content Accessibility Guidelines were introduced in 1999, they have been the reference point for making websites and digital products usable for people with disabilities.
Over the years, these guidelines evolved. WCAG 2.0 came in 2008, followed by updates 2.1 in 2018 and 2.2 in 2023. Each version added new criteria to keep pace with technology, but the structure itself stayed largely the same. It introduced four foundational principles that still shape accessibility today. Beneath these principles sat 13 guidelines and a series of testable Success Criteria.
To help organizations measure compliance, Web Content Accessibility Guidelines 2.x used a three-level conformance model:
- A: the most basic requirements, removing the most severe barriers;
- AA: the global benchmark, referenced by laws. Most organizations are expected to reach this level;
- AAA: the highest level, intended for exceptional accessibility but rarely required in practice.
For over a decade, this model gave governments and companies a clear legal and technical reference point. But it also revealed serious limitations:
- A website could be declared non-conformant due to a single error, even if thousands of other pages were fully accessible. This binary model discouraged incremental improvement and punished organizations with large or complex platforms.
- WCAG 2.x criteria were designed to be testable, so they often reduced accessibility to a box-checking exercise. Many organizations focused on audits rather than real user experience.
- Some barriers are not easily captured by yes/no rules. As a result, people with cognitive or learning disabilities were poorly served.
- The language of the guidelines was highly specialized.
- Emerging platforms (AR/VR, voice assistants, IoT) could not be fully addressed within the 2.x framework, which left gaps in guidance for building modern digital products.
These weaknesses created what many experts call the “compliance trap”. Organizations pursued Level AA certification to reduce legal risk, but this didn’t always translate into accessible or usable experiences for people with disabilities. The gap between “passing the test” and “enabling the user” kept widening.
The upcoming WCAG 3.0, currently in draft form and expected to be finalized later this decade, is different. Work on it has been ongoing for years.
What will change in WCAG 3.0
W3C Accessibility Guidelines introduces several fundamental changes that mark a philosophical and practical shift in how accessibility is defined and measured.
New philosophy of accessibility
The new version places user experience at the center. The main question shifts from “Does this pass the test?” to “Can a person with a disability actually complete their task successfully?”. It deliberately expands the focus to groups previously underserved by WCAG 2.x.
The development process was also shaped by this approach. The working group brought in people with disabilities as active contributors. This reflects the principle of “nothing about us without us”.
New structure of guidelines
The philosophical change is reflected in a new structure. The name has shifted to W3C Accessibility Guidelines. This signals that the standard is no longer limited to websites. WCAG 3.0 is designed to cover the entire digital ecosystem like mobile apps, software, PDFs, immersive technologies, voice interfaces, and the Internet of Things.
Internally, the framework has been rebuilt around three key layers:
- Guidelines are written in clearer, plainer language so that they can be used by designers, developers, content creators, and managers.
- Outcomes replace the binary Success Criteria of WCAG 2.x. They are measurable statements of whether a user’s need has been met. Unlike pass/fail rules, Outcomes are graded.
- Methods take the place of Techniques. They offer practical, technology-specific guidance on implementation and testing and also include examples, resources, and step-by-step procedures.
Bronze, silver, gold conformance levels
The old AAA/AA/A model is being replaced with a more intuitive system: Gold, Silver, and Bronze. Bronze will roughly align with the current global benchmark, WCAG 2.2 Level AA. This change reframes accessibility as a journey of continuous improvement.
This continuity ensures that organizations’ existing compliance efforts remain valid and form a solid foundation. From there, Silver and Gold encourage teams to go further by integrating more advanced usability testing, inclusive research, and design practices.
New scoring and testing model
Perhaps the most groundbreaking shift is the move away from a binary pass/fail system. In W3C Accessibility Guidelines 3.0, each Outcome is scored on a scale from 0 (Very Poor) to 4 (Excellent). This creates space to acknowledge partial success and track progress.
The scoring system blends different types of tests:
- Atomic tests check components (e.g., buttons, form fields). Unlike before, these can now produce binary, percentage-based, or qualitative results.
- Holistic tests apply to higher conformance levels and require usability evaluations with real users with disabilities, expert reviews, and testing with assistive technologies.
To safeguard against loopholes, the model introduces the concept of Critical Errors. A single barrier that prevents a user from completing a key task automatically invalidates conformance, regardless of other scores.
Scores are also balanced across Functional Categories, ensuring that a product cannot excel for one disability group while failing another. For the first time, achieving higher conformance will be impossible without engaging directly with people with disabilities.
APCA color contrast algorithm
W3C Accessibility Guidelines 3.0 replaces the old color contrast formula. The long-standing 4.5:1 ratio has always been easy to calculate but often misaligned with human perception. Designers frequently saw “passing” color pairs that were hard to read and “failing” ones that looked perfectly fine, especially in dark mode or with certain hues like orange and yellow.
The Advanced Perceptual Contrast Algorithm (APCA) addresses this by using modern vision science to model how people actually perceive contrast. APCA takes into account:
- Font size and weight (smaller, thinner text needs higher contrast);
- Foreground/background relationships (light text on dark backgrounds is perceived differently from the reverse);
- Differences in perception.
Instead of ratios, Advanced Perceptual Contrast Algorithm produces a Lightness Contrast (LC) score on a scale from 0 to 100+. The required LC depends on the text’s context (e.g., body text may require 60, large headlines may only require 45).
WCAG 3.0 vs WCAG 2.2: key differences
| Aspect | WCAG 2.2 | WCAG 3.0 |
|---|---|---|
| Name | Web Content Accessibility Guidelines | W3C Accessibility Guidelines |
| Scope | Primarily websites and web content | Primarily websites and web content Full digital ecosystem (web, apps, software, AR/VR, IoT) |
| Philosophy | Compliance-focused: “Does it pass?” | User-focused: “Can people with disabilities complete their tasks?” |
| Structure | Structure 4 principles → 13 guidelines → Success Criteria | Guidelines → Outcomes → Methods (clearer, layered structure) |
| Success model | Binary pass/fail Success Criteria | Scored Outcomes (0–4 scale), allowing degrees of success |
| Conformance levels | A, AA, AAA | Bronze, Silver, Gold |
| Testing approach | Technical audits and checklist testing | Combination of atomic (technical) and holistic (usability) tests |
| Inclusion of users with disabilities | Limited involvement in guideline creation | Active participation in development and testing (“nothing about us without us”) |
| Scoring system | Pass/fail only, no partial credit | Scored Outcomes, critical errors, functional balance across disability types |
| Color contrast | 4.5:1 ratio (simple but flawed) | APCA (Advanced Perceptual Contrast Algorithm) with LC score based on human perception |
Will W3C accessibility guidelines 3.0 shape the work of designers, developers, and businesses?
Yes, the new version will influence the workflows of some specialists, but not as radically as it may seem at first glance. Many of its principles build on what professionals are already doing.
For designers
Many of the tasks described in WCAG 3.0 are not new to designers. Good UX/UI practices have traditionally included selecting colors that are readable, establishing simple flows, and lowering cognitive burden. The degree of formalization and attentiveness is what changes with the new rules. Once “nice to have” items will be quantifiable results that directly affect accessibility ratings.
W3C Accessibility Guidelines 3.0 does not reinvent design work. It codifies the principles that good designers have always followed and raises the bar for everyone else.
For developers
WCAG 3.0 will change the way accessibility is built and tested in code. Teams will have to work with graded scores rather than comparing them to a fixed list of pass/fail rules. As a result, automated accessibility testing techniques will need to advance so they can determine where the gaps are and how much of the material satisfies the standard.
Many outcomes (e.g., whether navigation works smoothly with a screen reader) require manual review. Developers will need to integrate these checks into their workflows and allocate resources for real user testing.
The move toward scoring will also change how code is maintained. CI/CD pipelines, for example, can be configured to track accessibility scores and flag regressions automatically. This allows developers to prevent issues from being introduced with new commits, much like they already do with performance or security metrics.
For businesses
Compliance with WCAG 2.x was frequently viewed as legal risk management, requiring a minimal investment to prevent lawsuits. The new framework makes it possible to define accessibility as a measurable KPI, track progress over time, and benchmark against competitors.
This establishes a direct connection between accessibility efforts and company expansion. Companies that embrace these principles early will access a vast underserved market (more than 1.3 billion people with disabilities and their extended networks), strengthen their reputation for inclusion, and achieve higher conformance levels validated by users with disabilities.
The coexistence of WCAG 2.2 and WCAG 3.0 (as the forward-looking benchmark) will require balancing two parallel accessibility standards for years to come. But forward-thinking organizations can use this transition to their advantage.
How to prepare for WCAG 3.0 compliance: 5 tips from Rubyroid Labs
From our work with end-user and enterprise platforms, as well as accessibility audits, we know that the most effective strategy is to build readiness in stages.
Here are several practical moves teams can make today to avoid a painful transition later.
1. Check current WCAG 2.2 compliance
The best preparation for W3C Accessibility Guidelines 3.0 is solid compliance with WCAG 2.2 AA. This is still the global legal standard and it overlaps with the future Bronze level. A thorough audit of your key digital products against WCAG 2.2 will uncover recurring issues. Your team will have a solid foundation for future work if those gaps are filled now rather than later.
You can read more about the importance of UX/UI audits in the article Why UI/UX Audit Is Important at Different Stages of a Product’s Lifecycle.
2. Build accessibility into daily workflow
Fixing issues once is not enough. Like performance or security, accessibility must be safeguarded against regressions. Teams should establish clear governance: automated scans in CI/CD pipelines, regular manual audits, and prioritized remediation plans. We’ve seen at Rubyroid Labs how adding even little procedures (like accessibility checklists in pull requests) helps maintain standards-aligned products.
3. Involve users with disabilities into the process
Future Silver and Gold levels will require direct validation from people with disabilities. Start building relationships with diverse user groups now. The sooner companies start running small-scale inclusive research, the smoother the transition will be. Beyond compliance, these sessions often uncover usability insights that improve the product for everyone.
4. Track accessibility scores as KPIs
Formalize the “Accessibility Score” as a key performance indicator for product quality. This metric should be tracked on product and executive dashboards, reported on regularly, and used to set strategic goals for improvement. This elevates accessibility to a core business objective, which ensures it receives the sustained attention and resources necessary for success.
5. Build team-wide accessibility awareness
Accessibility should not be siloed with designers or QA specialists. Every role from product managers and business analysts to developers shapes the experience for people with disabilities.
Investing in training, workshops, and cross-functional sessions helps teams understand who they are building for and why certain decisions matter. Once teams see real examples, they start to connect their daily work with real users’ lives, and accessibility becomes a natural part of the process.
If you want your product to meet the needs of a broader audience without restrictions on age, abilities, or cultural differences, read the article Inclusive Design: How to Create an Interface That Works for 100% of Your Audience.
Conclusion: why start preparing for WCAG 3.0 now
The upcoming W3C Accessibility Guidelines 3.0 responds to the long-standing weaknesses of WCAG 2.2 and reframes accessibility around real user experience. Organizations will use graded scoring, more comprehensible terminology, and a new Gold/Silver/Bronze model.
- For designers, the guidelines won’t rewrite their job but will formalize practices they already value.
- The change won’t drastically alter daily tasks for developers, but it will bring new testing procedures and a closer integration of accessibility into pipelines.
- Accessibility will change for organizations from a compliance box to a quantifiable KPI that is closely related to user trust, growth, and reputation.
The shift to WCAG 3.0 will take years, but those who start now will gain a stable foundation, smoother adoption, and stronger products.
