Scheduling Approach Tradeoff Discussion

[rachaelbradley]

We continue to discuss the plan for publishing WCAG 3. We are stepping back to discuss tradeoffs at the July 22nd meeting. To prepare, we are asking members to document the tradeoffs with different approaches so we can discuss them and determine how to possibly mitigate them.

Some definitions for use in this discussion are below:

High Priority Content

All of the goals for WCAG 3 are important but there are some topics that the group considers really important and previous conversations around modules have suggested could be created first. To date this includes:

• New requirements for coga and low vision
• Assertions (which supports adding provisions for coga and low vision
• Updating the color contrast algorithm
• Updating the conformance model
• Providing suggestions to regulators on how to use WCAG 3 (This is always a note in the option discussed below.)

Types of Publication:

Rec (Recommendation) Track Publication
Publishing a version of WCAG 3 that we are declaring as “done.” A rec track publication gets a number (3.0) and the next Rec Track Publication would get another number (3.1). An example of a rec track publication is WCAG 2.2.
Draft
Publishing an update to the working draft of the WCAG 3 document. An example of a draft is the working draft of WCAG 3.0.
Note
Publishing a Note track document, separate from WCAG 3. We would then include the relevant content in the WCAG 3 Rec Track document. Examples of notes are WCAG2ICT and Making Content Usable.

Each of the following questions is a comment below. Please reply directly to each question with your thoughts.

1. What outcomes should AG be aiming for when considering publishing new content to support accessibility? Examples of new content include assertions, new color contrast, or breaking up info and relationships.
2. What are the trade-offs of providing high priority content in a Note vs. in a Rec Track Publication?
3. What are the trade-offs with frequent smaller Rec Track Publications vs. a larger scoped release?.

[rachaelbradley]

1. What outcomes should AG be aiming for when considering publishing new content to support accessibility? Examples of new content include assertions, new color contrast, or breaking up info and relationships.

[lseeman]

My concern is to get proper inclusion of people with cognitive and learning disabilities included in WCAG. That is the main outcome I am concerned with

[alastc]

To summarise and clarify a little (I hope, and chair-hat off), where @MakotoUeki said:

I suggested that we should focus on the existing WCAG 2.2 and the web content to see and show how WCAG 3 will look. I prefer the small start.

Whilst I agree with using WCAG 2 content when possible, at the very least it will need re-structuring to "show how WCAG 3 will look".

For example, we are splitting things into foundational & supplemental so that will change many SCs (e.g. "does something exist", and "is it any good" can be separated). Somethings might go into assertions because they are less testable (on a binary scale), such as caption quality.

@reidmore-online wrote:

I think we should actually deprioritize a focus on "replacing" WCAG 2, and focus instead on the actual problems we see for accessibility and let ourselves be surprised by the outcomes.

Ok, so if we've explored that, where does it go?

@ljoakley wrote:

My concerns are for the project as a whole. At the begining of each guideline there should be an easy to understand in layman's language guideline and a much more technical description following this for deep dives.

We have some restrictions in that the normative text on the face of the spec needs to be objective and correct. We can say more, we're less restricted than the structure of WCAG 2.x, but we will have to rely on informative docs to provide easier versions.

@ChrisLoiselle - We are aiming for the coverage to be applicable to digital interfaces in general. Although as W3C we'd write methods & tests for web technologies, but it should make it easier to write WCAG2ICT / mobile in a way that fits in with the overall guidance.

[julierawe]

I disagree with the folks above who want to prioritize converting WCAG 2.2 into WCAG 3. If we "build the new foundation first with the stuff we know, then stack up new stuff on top of that," we may end up with a WCAG 3 foundation that doesn't allow for new content that covers a broader range of disabilities.

I think we should prioritize focusing on cognitive and low vision first.

[rainbreaw]

Regarding this, "Providing a version of WCAG 3 that can replace WCAG 2 as soon as possible" -- is there a world were the two can live side-by-side, and WCAG 3 is able to continue to expand as we have parts ready? For example, we've been doing a lot of work on Clear Language, Lists, Clear Starting Point, etc. just to name a few. None of these are in WCAG 2. Is there a reason not to start publishing WCAG 3 with just the parts we have, let both WCAG 2 and WCAG 3 exist together, and then over time deprecate the parts of WCAG 2 that are no longer needed once WCAG 3 covers them?

[alastc]

Summary 29th July 2025

Points I could pick out from the comments, answering "What outcomes should AG be aiming for when considering publishing new content to support accessibility?"

• Modest adjustment of problematic WCAG 2 criteria (see Detlev's comment for examples)
• Test a new conformance model that has pass/fail wherever practical but allowing for degrees on those requirements / SCs that so far haven't allowed nuance.
• Put in place a new structure that:
  • is broader in technology coverage
  • allows for broader disability coverage
  • better adapts to user-agent & authoring tool improvements (including AI/ML tools) that can reduce the author effort.
• Getting a new replacement version out quickly (implicit in several comments, explicit in one.)
• Improving contrast requirements
• Prioritize content that answers/addresses some of the problem areas we have seen, rather than prioritising a 'replacement' version.
• Better inclusion of people with cognitive and learning disabilities included in WCAG.
• Ensure the new structure (including better for COGA) is in place, rather than building from WCAG 2.
• Publish the new things, whilst still having WCAG 2. (We would be in the normal course of things, but as drafts).
• publish new Requirements in Rec Track format sooner rather than later in order to get regulators and companies to adopt

[rachaelbradley]

2. What are the trade-offs of providing high priority content in a Note vs. in a Rec Track Publication?

[alastc]

(Chair hat off)

My assumption is that we would either:

• Work on WCAG 3 and carve off bits to publish as notes. For example, assertions and contrast-update.
• Work on adding bits with a starting point of WCAG 2.2. For example, assertions and contrast-update.

I don't think there would be much difference in timing, both could be done in a charter period.

The differences I forsee are that:

• A rec track doc is firmer, and could potentially be taken up by some regulators, although they don't work in 2 year increments so that's pretty unlikely.
• It will take much longer to get to a fully done WCAG 3 if we take an incremental approach (see next question).
• Notes could be written to apply to WCAG 2 without binding the final version of WCAG 3.
• Given that regulator uptake is unlikely, notes can be taken up by those who wish to use them.

Just on the usage of our notes in general, they are sometime thought to be unused but I'd point out that:

• WCAG-EM formed the basis for at least one government's testing approach.
• People are bursting to use a new contrast algorithm (at least if it provides designers some more asthetic options), so I think the uptake of that one would be high.
• I personally recommend COGA-usable to designers and UX folks regularly, it's a great resource, but it's hard to tell how much it is used.

Overall, I think this question is slightly less important than the next one (on incremental vs larger scope).

[MakotoUeki]

+1 to Gregg. Note(s) will allow us to share what we've got at that moment sooner and get more feedback.

[reidmore-online]

Nothing is stopping us from doing both. When I suggested notes I was thinking we could almost do a two-pronged approach where Notes allow us to work on and ship content focused on key problems we explore, and based on the work done in the note, we port normative content to a rec-track document that is updated as more notes are shipped. The notes could form the basis of the WCAG3 understanding documents as well. Notes let us work fast and develop ideas that could become normative as they are developed, while getting fast feedback.

[alastc]

+1 to @reidmore-online, assuming that the "rec track doc" is a draft. If we lock down guidance in one area (e.g. contrast) we'll need to update other areas in a backwards-incompatible way. The advantage of a note is that it can stand alone and we are still free to tweak the WCAG 3 draft.

[alastc]

Summary 29th July 2025

Points I could pick out that answer the question "What are the trade-offs of providing high priority content in a Note vs. in a Rec Track Publication?"

• A note would allow you to include all information and all advice rather than just the testable aspects. it also allows you to update more easily - and things are changing fast. Then later follow up with Rec Track that follows and makes the testable - regulatable bits part of a standard.
• Publishing a Note takes less time and less time away from publishing WCAG 3 as a whole
• Publishing a Rec Track Publication ensures more in depth review of the content before publication
• Publishing content in a Note allows for additional changes as the rest of the concepts mature without changing Rec Track content
• Publishing new content in a Rec Track document that also includes content from WCAG 2 so that it is a complete that has not yet been replaced may encourage regulators to adopt it. Notes have not yet been adopted in regulation.
• It will take much longer to get to a fully done WCAG 3 if we take an incremental approach.
• A note is not normative, a Rec track publication is.

[rachaelbradley]

3. What are the trade-offs with frequent smaller Rec Track Publications vs. a larger scoped release?

[alastc]

Hi @WilcoFiers, chair-hat-off responses:

We've had no problem getting previous versions of WCAG adopted...

We haven't done a backwards-incompatible version since WCAG 2.0 was adopted. Any incremental or wide-scope version we're talking about would be backwards-incompatible, so it is not the same situation.

Incremental doesn't mean we keep updating the same thing over and over. What we put in rec should be mature enough that we can leave it unchanged for the next decade while we work on other things.

I don't understand how we would achieve that, it sounds like you want to do a small update that could last a decade? Could you elaborate? For example, if we work on a specific area like contrast, what do we do with WCAG 2 criteria we haven't spent time on?

Smaller changes means less feedback to get through, fewer objections to resolve, less implementation efforts,

I agree that each increment would have less feedback etc, however, at each increment the rest of the normative text will need updating or mapping. At each increment we'll need to address the overlap / alignment with other areas. For example, contrast updates would impact text-appearance, focus-styles, non-text contrast, form-elements. These are (in the current structure) separate areas.

We'd spend more time mapping the changes and making normative updates across the document, as well as the time needed to go through the publishing process.

The alternative is to keep everything in draft for a while so we can easily make changes across the whole draft until we've got a reasonable amount of content incorporated and are confident in the structure. One of the approaches was 2 years to a draft, 2 years of feedback (and writing informative docs), not 6 years.

It's much easier for an organization to make three smaller changes over the course of six years than it is to do nothing for six years, and then having to make a large change.

In my experience it really comes down to the motivation for change. Most organisations I've worked with are either "just use the latest", or "what am I obliged to use". The former group are forward looking and will use whatever, the later rely on regulation.

Smaller increments would be easier to make, a larger one will make more noise and gather more interest.

another benefit of incremental is that we'd be better able to adjust our priorities based on changes in technology and the political landscape.

If it is as simple as deprecating a requirement, we can do that in WCAG 2.x. What is more difficult is adapting guidance because in some scenarios things have changed.

That would be easier to do in a newer structure that is less technology-specific, like the proposed structure. Unfortunately that also means re-structuring & re-writing existhing guidance.

[alastc]

Summary 29th July 2025

Points I could pick out that answer the question "What are the trade-offs with frequent smaller Rec Track Publications vs. a larger scoped release"

• Focusing on smaller Rec Track Documents makes new content available in a potentially adoptable form sooner rather than later
• Focusing on larger scoped releases makes WCAG 3 as a whole available sooner (the more smaller scoped Rec Track releases, the longer it takes to get to the entire scope)
• The overlap/alignment of requirements means that each update has a mapping of changes to previous versions, it wouldn't be backwards compatible.
• The extra overhead of publishing (about 6 months of each 2 year charter period) it will take longer to make progress incrementally.
• We can share what we've done at the moment by publishing the drafts regularly. No need to take more time for frequent smaller Rec Tracks.
• Getting new guidance out (even not taken up by regulators) on areas of concern will allow people to use it.
• Smaller changes means less feedback to get through, fewer objections to resolve, less implementation efforts, etc.
• Incremental is that we'd be better able to adjust our priorities based on changes in technology and the political landscape

[WilcoFiers]

We haven't done a backwards-incompatible version since WCAG 2.0 was adopted. Any incremental or wide-scope version we're talking about would be backwards-incompatible, so it is not the same situation.

I don't see why these would not be backward compatible? You add new things, then you deprecate old things. That's what we did with WCAG 2.2 - which we did consider to be backward compatible. That's the thing you wanted to do isn't it? Not to update WCAG 2.x content, but to everything for WCAG 3 be new. Well then by what we did for 4.1.1 parsing, the incremental approach would be backward compatible. We probably should still change that to 3.0 because we're making a substantial change to the standard. This is only a problem if we do a bad job of it, so let's just not.

I don't understand how we would achieve that, it sounds like you want to do a small update that could last a decade? Could you elaborate? For example, if we work on a specific area like contrast, what do we do with WCAG 2 criteria we haven't spent time on?

What I'm suggesting is that we focus on (for example) the contrast outcomes. Once they are ready we add them to our 2027 Rec in the "outcomes" section, we add a new "success criteria" section to WCAG 3.0 and we mark the contrast success criteria in there as deprecated, as they are superseded by the new outcomes. What I think we shouldn't do is get those contrast outcomes into rec in 2027, and then update them again in 2029 or 2031. We'd need a very good reason to do that because that actually would be a backward incompatible change.

The extra overhead of publishing (about 6 months of each 2 year charter period)

Where did you get that 6 months from? If that's true that feels entirely acceptable to me. We're taking a 6 month delay in the next two years so that we can get the most important accessibility updates out by 2027 instead of in 2031. Since that keeping everything in draft until 2031 will mean a longer RC period, let's be generous and say 12 instead of 6 months. That still means we get 90% (20 quarters of writing drafts instead of 18) of the work done with the incremental approach, with all the advantages it gives of delivering the most important improvement 4 years earlier.

And the reality is that we don't need to stop working on drafts just because we're going through rec track. It'll take up some time, but it's not like the entire group will be busy with rec track work. ARIA does this all the time, they have a doc going through rec track while they're working on the next one. It doesn't slow them down much.

[reidmore-online]

Something I feel needs to pointed out about the publishing process and it's impact on the group is that the logistics of transition requests, horizontal review, issue management, and preparing publications for CR/Rec is not a "whole group" activity. For horizontal reviews, there can be some elements where groups need to get together to discuss or solve issues raised by the horizontal review, but for the work, generally it doesn't involve the group. In my experience in other WGs, we've often cancelled meetings during these periods because there just isn't anything happening outside of the work of chairs/editors/horizontal review helpers.

In our case, publication does not need to put a halt on things, we can parallelize if needed. I'm a proponent of us actually only publishing "rec" once, when we consider WCAG 3 v1 "complete" (or as complete version 1 would be), which means this is not a concern. If we intend to follow a path where we do a publication cycle on a routine basis, we should consider parallelizing the work.

[alastc]

Hi Wilco,

I don't see why these would not be backward compatible?

We did consider WCAG 2.2 backwards compatible, and it's a good example. We can no longer (usefully) add requirements to that whilst maintaining backwards compatibility, it has proved too difficult. It is now stuck.

• If the contrast algorithm is updated, some sites would not pass 3.0 that did pass 2.2, and vice-versa. Therefore it would not be backwards compatible (in how we've talked about that before, and I think that is how regulators view it as well).
• If we update 1.3.1, break it apart, and/or make somethings 'foundational' some things 'supplemental', that would not be backwards compatible.
• Even if we just updated focus-appearance, focus-visible, and use-of-color to make them more rational together, there would be instances where the scope changes slightly and some pass/fails would change.
• If, once we have updated contrast, in the next increment we changed some aspect of form-requirements, that will probably impact the contrast guidelines. We've hit that before in 2.x.

The core problem is that accessibility requirements are not modalizable in any reasonable way. Most requirements overlap in which disabilities they support, and things like contrast overlap with multiple areas (like text, graphics, form elements etc). That was shown when we did the IA work before. Whatever aspect you update will have cascade effects to other requirements.

Therefore it is really, really hard to make updates that don't spill over into other areas, which makes backwards compatibility an issue whenever you change or replace things (rather than just add them).

If you also assume that we are trying to make these requiremments more widely applicable across technologies, and better able to allow for UA/AT/AI improvements to acheive outcomes, we can't just re-use WCAG 2 content.

Where did you get that 6 months from?

WCAG 2.1 and 2.2 were a bit longer than 6 months I think? There is a W3C tool that provides timelines for publishing, and I think the minimum timeline was 6 months.

I take your and Wendy's point that it isn't a whole group activity for the whole time, but it does take time & focus from the editors.

Also, if we are going to be fair about timeline references, the faster wider-scope option was aiming for 2029, not 2031.

[WilcoFiers]

@alastc W3C is rolling out a faster RC process. I think ACT Rules format 1.1 may actually be the first using it? Essentially we can now do CR and PR work in parallel instead of one after another. That alone saves 6 weeks.

We did consider WCAG 2.2 backwards compatible, and it's a good example. We can no longer (usefully) add requirements to that whilst maintaining backwards compatibility, it has proved too difficult. It is now stuck.

Right, but I'm not suggesting we add new success criteria. We write outcomes and assertions like we've been doing, and when we get to publishing, we have one section with outcomes, one with assertions, and one with success criteria. We can mark criteria that are superseded by outcomes as deprecated.

If the contrast algorithm is updated, some sites would not pass 3.0 that did pass 2.2, and vice-versa. Therefore it would not be backwards compatible (in how we've talked about that before, and I think that is how regulators view it as well).

I think that's pretty reasonable if we do that through deprecation. What I've been against (and still am) is updating existing requirements. We shouldn't update Target Size Enhanced for example in 2.2, because it means someone can pass the WCAG 2.2 version of that criterion but fail the WCAG 2.1 version. That's a mess we need to stay clear of. But that doesn't happen with deprecation. Let's say we do 3.0 in 2027 and 3.1 in 2029, where we end up deprecating criteria that were in 3.0. Than to conform to both 3.0 and 3.1 what you'd have to do is also test the deprecated criteria.

We learned form WCAG 2 that not having a solution built in for replacing old requirements with new ones is a problem. So regardless of if 3.0 comes out in 2027 or 2031, we're going to need this. Might as well use it.

The core problem is that accessibility requirements are not modalizable in any reasonable way. Most requirements overlap in which disabilities they support, and things like contrast overlap with multiple areas (like text, graphics, form elements etc). That was shown when we did the IA work before. Whatever aspect you update will have cascade effects to other requirements.

I don't think this problem is as large as you are suggesting. Sure criteria are related, and some are closely enough related that it'd be confusing if we replaced some, but not others. But I think if we tried we could find reasonable ways to break these criteria into groups that we could write new outcomes for in batches. Working on related batches was something Gundula suggested, and had a good deal of support. Will that result in slightly odd combinations of old criteria and new outcomes, probably. But in my opinion its well worth it in order to start shipping 4 years sooner.

[alastc]

I don't think this problem is as large as you are suggesting.

I think it is, based on two things:

• How much overlap we found in WCAG 2.x when only adding things;
• How often each sub-group has to ask "is this part of our requirement, or is it taken care of over there?"

I can see the depreciation approach would help, but it also assumes that the scope of the criteria stay the same, which seems unlikely.

Also, it would be 2 years sooner, not 4.

[WilcoFiers]

I can see the depreciation approach would help, but it also assumes that the scope of the criteria stay the same, which seems unlikely.

Not really? It assumes we aren't going to have an outcome that covers both color contrast and video transcripts. I see now reason why we couldn't fold all the color contrast requirements into one massive outcome, or break them up into smaller chunks, or some other combination of that.

We may end up with outcomes that overlap some success criteria we haven't deprecated yet. But so what? We have success criteria that overlap each other today. Rather a lot of them actually.

Also, it would be 2 years sooner, not 4.

I thought what you were suggesting is that in 2029 we'd get a WCAG 3.0 that'd be roughly equivalent to WCAG 2.2, but that we wouldn't start addressing significant gaps until the 2031 release. Which sure, the difference between getting to rec is 2 years (2027 vs 2029). But the difference between when we'd start working on gaps in 4 years (2027 vs 2031), which is what I was referring to.

[alastc]

I thought what you were suggesting is that in 2029 we'd get a WCAG 3.0 that'd be roughly equivalent to WCAG 2.2, but that we wouldn't start addressing significant gaps until the 2031 release.

The idea of the shorter (wide-scope) approach was to be roughly equivalent in terms of size and scope, but to address at least some significant gaps. Contrast, assertions, plain language etc.

Some of that comes with including assertions anyway. Compared to the longer wide-scope approach, it wouldn't have time to turn some of the newer requirements into mature content.

There is some flexibility (and unpredictability) in all the approaches, but that seemed like a good compromise to getting the new structure out.

[goodwitch]

While I deeply value the great progress on taking WCAG 2.x SC and (breaking them apart) + (improving them) for WCAG 3.0....I think we need at least 1 step in between. We need an initial set of process assertions ASAP (waiting 4+ years is way too long).

Why are process assertions so important? Because a company may be able to honestly produce a VPAT that shows their product substantially meets WCAG at x point in time...but without things like:

1. A digital accessibility policy/statement
2. A designated employee responsible for governing digital accessibility
3. Usability testing with people with disabilities (on a reasonable cadence that doesn't break the bank)
4. (add your idea here for an initial process assertion)

the sustainability of accessibility is impossible.

I propose we have an interim step (published as rec by 12/31/2027) that includes WCAG 2.2 A/AA as is (okay, you can squeeze in a few changes) and adds well-defined process assertions (where the process assertion uses proof points to set the appropriate maturity level of 0-5: 0 Inactive, 1 Initial, 2 Managed, 3 Defined, 4 Quatitatively Managed, 5 Optimizing. See https://cmmiinstitute.com/learning/appraisals/levels

And for those who say, "but people can just lie" about their maturity level for the process assertion. Yep. They can. But they can also lie about meeting a WCAG SC. And we will define what the minimal proof points are to be able to accurately determine the maturity level of 0-5 for each process assertion.

[reidmore-online]

One aspect I believe is missing from this discussion, and that should influence or provide some context to how we approach the WCAG 3 schedule is where standards implementation is at currently in the regulatory space. I believe the publication of WCAG 2.2, and the upcoming iteration of EN 301 549 in 2026 have bought us some time. The problems everyone is raising about the need for things like process assertions are valid, but I believe we can address them with a modular method. Having some time means we don't need to rush something out for 2027, because even if we did, the likelihood of it being adopted would be another 3-5 years out at best.

Visualizing things helps me a lot, so I took the liberty of trying to draw out what I think might be a feasible path:

With a modular approach, we focus on producing informative (non-binding) documents that give us the ability to focus on specific problems, design outcomes for each problem space, and then feed those outcomes into the main draft. The modules and other informative documentation would be published as WG Notes, which are simpler to produce and have fewer restrictions on updating and maintaining. In addition to the modules on specific problems, we can also have streams for the conformance and assertion work, using our subgroups, which I believe are a really effective model for working already. The work of all these streams continually feeds into the WCAG 3.0 Draft, which we keep updated at a regular cadence. Once we feel we've reached completion, or at least a version 1 we feel covers as much as we consider reasonable, the informative work ends and we take WCAG 3.0 to CR, then REC.

I believe with the informative documents we also have the benefit of getting real-time feedback as we work, especially if we cater each module to specific accessibility areas like contrast or forms or media. We make sure we are clear that the documents are not normative (enforceable), but that we want people to use them, experiment, and give us feedback on whether they help address any issues people have with existing standards.

I did not put it in my visualization, but the CR/REC work frees us up to do other things in that phase, like write additional informative guidance on anything not covered in modules, or work on things like a WCAG 3 quick ref.

The primary trade-off here is that this method will mean a "final" WCAG 3 is likely not going to come until 2029-2031. However, we would have informative, functional documentation for the industry to use in the meantime, as we work towards the rec. I believe this would land WCAG 3 REC at a time when regulators would have an appetite to update standards, plus we'd have supplemental documentation to make that even easier for them.

We have been at this for a long time, so I understand the worry that we'd push the schedule out even further, but WCAG is no small feat, especially with the scope we're exploring. It is due to the time we've already spent on this that I think a better path is more functional documentation in the near term vs a complete REC.