The Accessibility Guidelines Working Group chairs and staff presented “WCAG 3: The True Story!” at CSUN 2025.  Due to time constraints, we were not able to answer all of the audience’s questions. We’ve posted the questions and answers below.

Q1 Research Accepted

You cited needing not just academic research. Does this mean peer review is not as much a concern for that research? Yes, I am thinking about APCA.

We are looking for research that:

• Provides transparent research methodology and results,
• Uses a methodology that makes sense for the research objectives, and 
• Presents unbiased evidence.

We recognize that well-done usability testing and other work can meet these criteria. While we value peer reviewed academic research, we will accept other research resources when they address the research questions. 

The research question depends on the requirement under discussion. For example, we often need to know whether to include a requirement or not, so the research needs to establish that the requirement helps people with disabilities.

Some requirements, such as colour-contrast or target size, sit on a continuum or include tradeoffs. For some people, the larger the target size the better, but requiring large target sizes will impact how many items can be included in a certain space. This also impacts the feasibility of certain designs. It can also negatively impact low-vision users who zoom in a lot as they can’t fit as many controls on screen.

Research is helpful to establish where on the continuum is best for what proportion of users (knowing that some will always want the maximum). Then there is a process of working with other stakeholders (e.g. design teams, people who work on brand guidelines) to work out what is feasible and realistic. There is also the option of enabling customisation rather than changing the default appearance.

Because of all these factors, the type and amount of research needed will vary by the requirement. 

Q2 AI Impact

Do you envision advances in AI as impacting any part of WCAG 3?

We assume it will have a large impact on how accessibility requirements are met. The structure we’re using allows for user-agents to meet requirements, so it shouldn’t require updates to the core guidelines when new technologies become widely available.

Q3 ARIA Use

How does the WAI Application pattern guide fit into the requirements? We are often pointed to that as the only way to meet a guideline in some cases.

Assuming this means the ARIA patterns, they are a way (a “method”) of meeting a requirement. They may not be the only way to meet something, but often they are a known-supported way to achieve something (e.g. tabs).

Q4 Conformance Reporting

Will conformance reports indicate if and where barriers may exist ? A more robust version of “comments” in the current VPAT?

The VPAT is not a W3C product. WCAG 2 doesn’t require conformance statements. Instead it presents the required parts of an optional conformance statement. That will likely be the same for WCAG 3. We haven’t defined the format of WCAG 3 conformance statements, but could certainly take input from other areas like VPAT and (EU) Public-Sector accessibility statements.

Q5 Web Based Documents

Would your web-only charter cover web-based documents such as PDFs?

WCAG 2.0 currently includes PDFs when they are at a URL, so are considered web-content. AG is designing WCAG 3 so that these will still be considered web based documents. The structure of WCAG 3 should also make it easier to apply requirements to non-web content, even though web technologies remain our focus. 

Q6 Accessibility Needs

What have been the most challenging accessibility needs to incorporate into a written standard?

Requirements that rely on context. For example, some requirements require certain spacing to support reading but the spacing needed will vary based on the writing system used (Japanese, Arabic, etc.)

Q7 Improvements to WCAG 2

What high level aspects of WCAG 2.x were you looking to improve

The WCAG3 explainer outlines the goals, and as we already have WCAG2, that works to show what we’re trying to improve. This includes a desire to:

• address more disability needs than WCAG 2,
• incorporate publishing requirements and emerging technologies such as web XR (augmented, virtual, and mixed reality) and voice input,
• facilitate maintenance, so that the new model will be more enduring over time as technologies evolve, and
• include additional information about the ways web technologies need to work with authoring tools, user agents, and assistive technologies.

Q8 Scope

Is the scope of WCAG 3 only web, or is it being created to be applicable to native apps, documents and other technologies?

The scope, under the W3C is “web technologies”. However, we are taking an approach of having general user-requirements at the top-level, and it should be possible to use the framework and requirements and fill in other technology-specific methods that are not included as part of WCAG 3.

Q9 Number System

Are we maintaining the number system for the new criteria?

No. 

Slightly longer answer: We do have numbers assigned to the sections which contain guidelines, but we do not intend to apply numbers to the specific requirements while writing the standard.  There is a cognitive overhead in trying to remember or interpret the numbers, and as we go through the drafting process they would change often. When we are done, we will discuss possibly adding some type of number system back in. 

Q10 Retrospective

What came out of the retrospective on monday, what were some of the themes discussed?

Most discussion was about how we work. There is a lot of parallel work being done right now so we need to coordinate effectively.  All of the substantive discussions are public, for example, after the retro we ran a workshop/meeting to work on the replacement definition for web-page. 

Q11 Informative Methods

You mentioned that methods are informative, is that a finalized decision? 

Nothing is finalised, however, it is very likely that methods would be informative as they need to be updated regularly. Making methods normative would make it much harder to update, as it would have to go through a long publishing and review process.

Introduction

This section covers the basics – what you need to know about the update and how to provide feedback. Read the full article for more interesting details.

The Accessibility Guidelines Working Group (AG) has updated the W3C Content Accessibility Guidelines (WCAG) 3 Working Draft. This post presents an overview of this update as well as AG co-chairs thoughts on the standard’s direction. 

The December 2024 update includes three guidelines that were used to explore how WCAG 3 might be structured: 

1. Image alternatives guideline
2. Keyboard focus appearance guideline
3. Clear meaning guideline

These guidelines are still developing and need a lot more work before they are ready to use. The AG would like feedback from you on whether the content organization and the labels (guidelines, foundational requirements, supplemental requirements, and assertions) make sense. 

Key questions for you to consider when reading the 3 developing guidelines:

• Does this overall approach help you understand what needs to be done to make content accessible? 
• How can it be improved?

The update also includes changes to the conformance section such as the overall approach to conformance and Section 3.1.1 Only accessibility-supported ways of using technologies.  You may notice that explanatory content from previous versions is no longer in WCAG 3. This content has been moved to the Explainer for WCAG 3, which was also updated.   

Key question for you to consider when reading the conformance section:

• Do you have concerns about the direction conformance is moving?

We publish twice a year to give you visibility into the working group progress and an opportunity to give feedback. We welcome constructive comments on the direction conformance is developing. We recommend reading this post, the conformance section, and the explainer before sending feedback. 

Should you wish to provide feedback after reading, please file a GitHub issue or send an email to public-agwg-comments@w3.org (comment archive). Please create 1 GitHub issue or send 1 email per topic – it makes our work much easier which leads to faster standards creation.

Caveats 

These may seem dull but these pointers are really important to remember.

The majority of this draft is still Exploratory. Even the most mature portions have only just moved into the Developing stage of our content maturity process. We expect them to remain in Developing for a while.  

What does that mean? It means this draft content will change.  

The Accessibility Guidelines Working Group wants public feedback on WCAG 3 early and often. 

Remember:

• This WCAG 3 draft doesn’t replace WCAG 2. WCAG 2 is used around the world and will still be required by different countries for a long time to come.
• Public feedback is an important part of the W3C process and the Accessibility Guidelines Working Group (AG) takes the comments we receive seriously.
• If you want to learn more about WCAG 3, please read the WCAG 3 Introduction.

Do not use this draft content as a standard or revise your accessibility program and goals to meet the contents written in this draft. We are not there yet!  If anyone tells you otherwise, they are uninformed or lying. 

WCAG 3 Structure

From here on, the content reflects the co-chairs thoughts about the direction this draft is taking. Not all AG members may agree but we hope it gives insight into the general direction and progress made. 

The proposed structure relies on Guidelines broken out into Requirements and Assertions. AG will be discussing including Recommendations.

Guidelines

Guidelines are written as user-centered outcome statements to make them easy to understand. These had been called Outcomes before and these were at various levels of detail. This draft clarifies the structure of Guidelines and Requirements.

Guidelines are organized into groups based on what is typically tested by that guideline.  POUR (perceivable, operable, understandable, and robust) is an excellent way to teach guidelines but many people reorganize WCAG 2 Success Criteria (SC) to facilitate testing.  The Web Accessibility Initiative (WAI) plans on building a tool that tags WCAG 3 requirements and allows users to reorganize them by POUR or other tags.

Requirements

Requirements are comparable to Success Criteria. AG changed the name so they are easily distinguishable as the required portion of this standard.  Requirements can be tested with repeatable results, though just like in WCAG 2, the requirements may need manual testing and educated judgement. 

Requirements are further divided into:

• Foundational Requirements – These requirements present core needs that must be met to support people with disabilities. These may be met by authors, operating systems, browsers, or assistive technology but they must be met. AG expects the list of Foundational Requirements will be similar to A & AA WCAG 2.2 with additional support for disabilities not included there. For example, AG is exploring requirements that only apply to specific languages or writing systems. These requirements would include conditions and a plan for internationalization.
• Supplemental Requirements – These requirements may include meeting a higher threshold than the Foundational requirements (think enhanced color contrast in WCAG 2) or they may best apply in specific situations. 

Assertions

Assertions have been discussed in previous drafts and continue to be an important part of WCAG 3. When making a conformance claim, assertions would allow the writer to state that they used a process to improve or verify accessibility such as using an accessible design system,  assistive technology testing, usability testing, or plain language testing.  

We are still working out how assertions will fit. For this draft they are included under Guidelines but they may be moved into their own section as we are finding that the same assertion covers multiple guidelines. You can read more about Assertions in Section 5.3 of the WCAG Explainer. 

Recommendations

The group will be discussing adding in recommendations.  Recommendations are best practices that improve accessibility but are not reliably testable. These have some overlap with Assertions and the group will need to spend time discussing this option and and trying these out before making a decision. You can also join the discussion about recommendations on GitHub.

The Goldilocks Organization Problem

One of the complexities in WCAG 2 is that a single sentence SC includes layers and layers of complexity. That makes the SC hard to write and hard to understand. We are attempting to break the complexity out into separate parts and create a structure that helps readers understand when to use each part. The challenge is finding the best balance between testability and complexity.

As we worked through this, decision trees became very helpful for the group. We have included some decision trees in this draft to get public feedback. 

From a chair perspective, we don’t think the current organization is quite right though we do think it is on the right track.  Some items we think need more work include:

• Moving the details that support testing out of the How To documents and Methods and back into the normative document.
• Refining decision trees by writing more examples.
• Trying out decision trees that include all the Requirements, Assertions and Recommendations that could support the guideline. In the current draft the decision trees only include the Foundational Requirements.

WCAG 3 Conformance

The AG has decided that:

“The most basic level of conformance will require meeting all of the Foundational Requirements. This set will be somewhat comparable to WCAG 2.2 Level AA.

Higher levels of conformance will be defined and met using Supplemental Requirements and Assertions. AG will be exploring whether meeting the higher levels would work best based on points, percentages, or predefined sets of provisions (modules).”

This short statement reflects a lot of research and testing to narrow down the approach. As a reminder, this is still in draft. The AG will spend the first half of next year working on the guidelines. The AG may, after testing, decide against this approach but this is the direction we will be moving until we prove it doesn’t work. 

Like WCAG 2, WCAG 3 will have a set of core requirements and an extra set of requirements. Unlike WCAG 2, conformance levels won’t map directly to those sets. The most basic level of conformance to the standard will be the Foundational Requirements plus some subset of the Supplemental Requirements and Assertions. 

AG will be exploring whether the author should select which Requirements and Assertions to meet in order to reach a certain number based on points or percentages OR whether AG will create modules of related content for authors to meet based on certain criteria. For example, a module about plain language may be more important for educational materials than for other types of materials.

As an example of how this might work, the most basic level of conformance (Bronze perhaps) might ask that content meets all the Foundational Requirements and 10% of the Supplemental Requirements OR all the Foundational Requirements and a plain language module. It is worth noting that many plain language requirements are being worked on as Foundational, rather than Supplemental requirements or assertions. However, some will likely fall into the optional grouping. 

WCAG 3 can only recommend conformance to its own technical specification.  It will be up to governments to write that conformance into law. One of the biggest risks of the proposed approach is that the legal standard will simply point to the Foundational Requirements, mimicking WCAG 2. However, the AG deemed that risk less severe than the risk that entire groups of people with disabilities would be left out if the conformance model gave authors the ability to choose which requirements to meet without constraints.

Accessibility Supported

WCAG 2 includes the concept of accessibility supported and conforming alternate versions but in our experience they rarely comes up in conversation outside the working group.

In WCAG 3, we are working to make these ideas much more visible. WCAG provides guidance for authors, not operating systems, browsers, or assistive technology. That said, whenever publicly available user agents like these are able to support accessibility requirements it reduces the burden on the author. 

In WCAG 2, the AG does not write guidance that user agents already support. There is no criteria for visible pointers because pointers are typically visible. The challenge with this gap is that when new technologies are developed, there is no complete list of criteria for new technology to meet. We are exploring the idea of using the decision trees in part to allow WCAG 3 to age gracefully by providing a list of criteria that user agents and new technologies can use to support accessibility. If user agents meet WCAG 3 guidance, authors could then focus on not breaking that support rather than building it in.

Next Steps

AG will spend the next 6 months focusing on moving all the guidance to the developing stage. This will include removing some guidance that needs additional research and looking for research partners willing to conduct that research. At the same time, we will be working to refine the structure in this draft and continue to address difficult topics such as third party content and complex, rapidly updating content.

Rachael, Alastair, & Chuck

Understanding the WCAG 3 Working Draft Update

The WCAG 3 Working Draft has been updated. WCAG 3 doesn’t replace WCAG 2. WCAG 2 is used around the world and will still be required by different countries for a long time to come. 

When we published the first public working draft, we received over 300 comments.  Public feedback is an important part of the W3C process and the Accessibility Guidelines Working Group (AG) took the comments we received seriously. We aggregated and organized the feedback and revised our approach to WCAG 3. 

Below is an overview of what you will find in this draft: 

• All content is labeled with content maturity levels: Placeholder, Exploratory, Developing, Refining, and Mature. There has been confusion in the past about how mature content is and when to adopt it. These maturity levels inform readers about how complete and ready to use each piece of content is.
• You will find a placeholder list of guidelines. We have temporarily removed all of the draft guidelines that were in earlier drafts of WCAG 3. These guidelines were initial examples.  Over the next 6-9 months we will be writing an exploratory draft of outcomes for each guideline. Part of this process will be updating previous draft content, such as the APCA approach for color contrast, and adding that guidance back in within the context of the full set of guidelines.
• This draft presents pieces of a conformance model which have shown promise during conversation and testing. These include conformance levels, percentages, pre-assessment checks, issue severity, and user generated content. This working draft does not contain a complete conformance model. We’ve reviewed numerous options but want to evaluate each for testability, repeatability, etc. before publishing the most promising model.
• The AG is applying a more granular way of thinking about guidance based on how repeatable test results are by the same tester and across testers. Clearly identifying when tests contain a subjective component will help when explaining and applying WCAG 3.
• We have added an approach that allows for guidance that only applies in certain conditions, such as situations where a specific language is used.
• We have also added “Assertions”. Assertions are statements about whether a process was completed. Examples of such processes include usability testing, plain language evaluations, and assistive technology testing. Testing an assertion only includes evaluating whether an organization made an assertion, and if the required documentation is complete. Testing an assertion does not test the results of the process. The hope is that Assertions will allow WCAG to promote certain processes that improve accessibility without requiring repeatable results.

You can read more about this update at the WCAG 3 Introduction.

We are not requesting wide review, that is, we are not looking for general public feedback on this draft, but you are always welcome to comment through GitHub. If you are not able to use GitHub, email public-agwg-comments@w3.org. Please create 1 GitHub issue or send 1 email per topic.

I will be posting additional details about WCAG 3 and the next steps for the Accessibility Guidelines Working Group over the next week or two.