In this post, I cover some of the stakes and challenges in developing W3C Accessibility Guidelines (WCAG) 3. I use “websites” as an example, yet this information generally applies to apps, software, documents, and other digital content and technologies.
Summary
You could say that ideally WCAG would cover all the accessibility needs of people with disabilities, accessibility would be easy to implement in all situations, and comprehensive standards would be implemented in all websites. Alas, our world is not ideal.
If WCAG required that all possible accessibility needs and wants are fully met, it would not be a practical standard that could be implemented by all websites.
If WCAG did not sufficiently address accessibility needs, it would not meet its primary goal. Thus WCAG needs to balance user needs with implementation practicalities. This is an incredible challenge.
The W3C Accessibility Guidelines Working Group is addressing this by covering as many user needs as possible in WCAG 3 and providing guidance on prioritizing implementation. We know that some websites will not go beyond the minimum requirements. We also know that some websites will go beyond the requirements and want to be recognized for providing more accessible websites.
We continue work on ways to encourage all websites to be as accessible as possible.
Different stakeholder needs and wants
People with disabilities need the web to be accessible. It’s imperative for equitable access to the digital world.
Most websites have accessibility barriers. To help address this, many countries and regions have laws, regulations, or policies that require websites to be accessible. Most are based on WCAG 2.
Policymakers want a stable standard that can be used to create practical regulations.
Some website owners and developers do not want to be required to make their website accessible. Some push for accessibility standards to have minimal requirements. (Factors that are not related to this blog post include awareness, education, accessibility of authoring tools, and more.)
These are some of the competing interests in developing accessibility standards.
Balancing stakeholder positions
Competing interests are a major challenge faced by the W3C Accessibility Guidelines Working Group as it develops WCAG 3.
We want WCAG to cover disabled peoples’ accessibility needs.
We want WCAG to be adopted and implemented.
As said in the summary above, if WCAG required that all possible accessibility needs and wants are fully met, it would not be a practical standard that could be implemented by all websites. If WCAG did not sufficiently address accessibility needs, it would not meet its primary goal.
An example is sign languages. Sign is the first language of some people, and some are not as literate in written text. Therefore, having all content also available in sign languages would be most accessible. However, it is not practical to require sign language because it is expensive, there are limited resources (including signers) to get it done, and there are multiple sign languages even in English. WCAG includes sign language as an accessibility need, just not as a requirement for conformance. And WCAG requires that all auditory information is available as text, not just audio.
To address multiple stakeholder interests, working group participants bring experience from multiple perspectives, including people with a wide range of disabilities, government, implementers, multinational corporations, small businesses, and more.
Over the last few years, the group has explored many different approaches. We are particularly excited about the latest approach. Fundamentally, it simplifies conformance to the standards and provides flexibility for defining policies. It also encourages going beyond conformance to address additional accessibility needs.
I’ll say more later; first let me explain a bit about conformance.
WCAG is the ruler
One way to think about the standard and policies is as a measuring ruler and rules.
- Ruler — The WCAG standard documents accessibility requirements. WCAG can be used to measure accessibility.
- Conformance — When a website meets specified WCAG requirements, it “conforms” to WCAG.
- Rules — Laws, regulations, and policies define which WCAG requirements must be met. Policies can include and exclude WCAG requirements.
- Compliance — When a website meets a law, it “complies” with that law.
W3C provides the ruler with WCAG.
W3C does not write the rules. Yet we know that WCAG is used in laws, and that factors into WCAG development.
Defining and measuring challenges
WCAG as the ruler and policies as the rules is a nice simple analogy. Yet even defining the ruler is complex.
With digital accessibility, some things apply in all situations and can be fairly easily measured. Yet many things are difficult to define and measure.
Many depend on context. And context impacts the importance. For example, an accessibility barrier in a form to pay my community chorus dues is not nearly as important as a form to apply for medical treatments.
The W3C community has iterated through different approaches to covering accessibility needs that are difficult to address as requirements in a standard that is often required. (more below)
A fundamental shift
The W3C Accessibility Guidelines Working Group has spent time and effort exploring different approaches to conformance for WCAG 3, especially considering that WCAG is used in policies. Much of the previous work on draft conformance was trying to address more things within WCAG and provide flexibility within conformance.
The September 2026 draft of WCAG 3 takes a fundamentally different approach. It further separates conformance to WCAG from details that can be addressed by policies. It defines reporting tiers to encourage greater accessibility towards conformance and beyond conformance. It provides several aspects for policymakers to choose WCAG requirements for different situations.
Specifically, this WCAG 3 draft provides:
- a single level of conformance
- called “core requirements”
- builds on WCAG 2.2 Level A and AA success criteria
- provides a baseline for policymakers
- supplemental requirements, assertions, and recommended practices
- cover areas that cannot be objectively measured or do not apply to every situation
- encourage organizations to improve their approach to accessibility
- encourage websites to go beyond conformance
- “tags” that can be used
- by regulators to define policies that include and exclude specific requirements for specific situations (for example, more requirements for essential government services and fewer requirements for less important websites)
- by websites to report progress towards conformance and beyond conformance
- multiple reporting tiers to encourage greater accessibility
This approach simplifies what is considered WCAG conformance and provides flexibility for more specific website reporting and policy development.
Continued WCAG 3 development
We now have an approach that shows promise in balancing the challenges introduced above.
The Working Group welcomes constructive input as it continues to explore and refine the approach and the details to craft a WCAG 3 standard that:
- defines ways for websites to be more accessible to more people with disabilities
- makes it easier for website owners and developers to understand what they need to do
- provides policymakers with an international standard that is flexible to meet different policy contexts
- encourages website owners and developers to improve accessibility by acknowledging success towards conformance to WCAG 3 and beyond conformance
- works in context now and in the future
WCAG is a tool
With all this focus on WCAG, I want to clarify that the goal of accessibility is to meet the needs of disabled people in the real world. WCAG is an important tool for accessibility, yet just meeting WCAG is not the end goal. And meeting only the WCAG 2 Level A and AA success criteria (or only the core requirements of WCAG 3) is not enough. WCAG and policies help motivate, measure, and report on accessibility. Accessible user experiences is the goal.
W3C provides resources to understand disabled people’s experiences and to encourage user-centered accessibility.
We plan for the WCAG 3 documents to further support a user-centered accessibility approach.
Learn more and share
To learn more about WCAG 3, start from the WCAG 3 Introduction. It includes review questions and how to submit comments.
We look forward to your input on crafting WCAG 3 to encourage more accessible user experiences in the real world.
Finally, a huge thanks to the Accessibility Guidelines Working Group Co-Chairs, participants, and everyone who contributes constructive perspectives for developing WCAG 3.