Many organizations have resources that are used with different versions of WCAG 2. Think of training courses, templates, test tools, etc. The W3C have many such resources too.

Presumably, those resources, templates, etc are dated/scoped specifically to whichever WCAG version was stable at the time?

Then there's the challenge people who're still using 2.0 and 2.1 face. What are they going to do with a success criterion that is removed from WCAG 2.2?

If they're working to 2.0 or 2.1, then they follow 2.0 or 2.1. That's how versioned versions of a standard work, no?

Deprecating SC 4.1.1 seems like a much better thing to do. It's still there, it's still required, but everything that you should fail under it is a failure somewhere else, and so feel free to skip it if you want to

... I fail to follow. So you mean it's there, but an automatic Pass? Is that any better/more logical? How does that help in the scenario you raise about "people who're still using 2.0 and 2.1"? How does that help "organizations [that] have resources [...] for different versions of WCAG 2"? what, materially, makes deprecation/auto-pass versus removal better?

I completely agree with everything @WilcoFiers has said. If we insist on removing 4.1.1, then lets bite the bullet and number it 3.0 instead of 2.2. This would make breaking changes acceptable.

The arguments around cost seem misplaced when the most impacted are organisations making very large sustainable profits, what should come first is what's best for disabled people and the wider community.

If we insist on removing 4.1.1, then lets bite the bullet and number it 3.0 instead of 2.2. This would make breaking changes acceptable.

how does renaming 2.2 to 3.0 make any material difference, again, to the problems wilco listed?

Do you remove it from the resource, and so removing it from WCAG 2.0 and 2.1?

Assuming that the resources are versioned, then remove it from 2.2 resources.

If they are not versioned, then you'd need to decide the point at which to update.

If so, what do you call a criterion that is removed in one version, but not others?

That's entirely up to the people making the resources. It feels like there's a nomenclature issue I'm not understanding here.

So for ACT rules we probably can't remove rules.

We've removed techniques (informative content) previously, why not ACT rules?
Also, how many 4.1.1 rules would be affected? I saw one from a quick scan, but I didn't do a thorough check.

Deprecating SC 4.1.1 seems like a much better thing to do. It's still there, it's still required, but everything that you should fail under it is a failure somewhere else, and so feel free to skip it if you want to.

So in effect it is removed...? I'm struggling to see any practical difference.

Re-map relevant tests to other SCs, which works for previous versions as well.

What are they going to do with a success criterion that is removed from WCAG 2.2? Can they stop testing it? Is that contractually, and legally allowed?

Some large organisations (with plenty of lawyers) are already stopping their testing of it. I'm not convinced there is a legal problem there. Anything currently required is under 2.1, any future updates to 2.2 change the testing. (Mostly increasing, but decreasing in this one area.)

In practice some of the testing methods from 4.1.1 (e.g. checking for duplicate IDs) can guide manual testing of 1.3.1 / 4.1.2, but wouldn't be automatic fails any more.

It is also a nuance of "backwards compatible": From an accessibility requirements point of view, this is a backwards compatible change because it doesn't impact accessibility for people. The useful parts can be caught by other SCs.

It's still there, it's still required, but everything that you should fail under it is a failure somewhere else, and so feel free to skip it if you want to.

I really don't understand the difference here. It seems like a way of making it more confusing as it would still be there, and required(?), but you can skip it if you want to? I'm missing something.

This should be done along with an errata for WCAG 2.0 and 2.1 so there are no concerns about differences in different versions.

I'm not sure what you mean here, would that be an errata to mark them as deprecated? Or the one discussed about clarifying the syntactic interpretation?

I was under the impression WCAG was using semantic versioning, especially since the backwards compatibility from 2.0 to 2.1 was heavily emphasized as a great benefit.

Under semantic versioning, removing an SC would most definitely constitute a breaking change and thus require an increase of the "MAJOR" version number, therefore WCAG 3.0.

It is then also customary to inform dependents and allow them time to prepare for such a change, by marking something that you are planning to remove as deprecated at least one "MINOR" version before the removal.

In fact, in a lot of cases, items are only ever marked deprecated and never actually removed to preserve maximal backwards compatibility, unless it prevents progress.

WCAG is a set of regulations, not some software library...

And again, if you want to get all semver, and say that this should be WCAG 3.0 if it removed anything...how, materially, does this address the points wilco mentioned in the OP?

Incidentally, didn't we already have discussions about versioning and how it complicates matters for the move of 2.4.7 Focus Visible from AA (in WCAG 2.0/2.1) to A (in 2.2)? Another case where documentation, advice, etc needs to be updated/versioned.

WCAG is a set of regulations, not some software library...

Of course, but semantic versioning can be applied usefully outside of software.

And again, if you want to get all semver, and say that this should be WCAG 3.0 if it removed anything...how, materially, does this address the points wilco mentioned in the OP?

If you are OK with just making a breaking change without allowing people time to prepare for it, then no, simply changing the version won't help much. It would send the clear message that there is a breaking change and send people scrambling, but that's about it.

But you don't want people to scramble. You want people to be well aware and prepared for breaking changes. Increasing a "MAJOR" version should be a heavy decision.

Marking something as deprecated only requires a "MINOR" version upgrade, and eases the transition towards the eventual "MAJOR" version upgrade.

However, discussing semantic versioning in depth here is probably too much of a tangent, it is more a useful analogy, because WCAG isn't a software library.

I think the original point is sound: Removing an SC is probably too disruptive to do on short notice. Marking it deprecated for now would be a solution to reduce the disruptiveness of the change in the future.

@patrickhlauke:
If they're working to 2.0 or 2.1, then they follow 2.0 or 2.1. That's how versioned versions of a standard work, no?

WCAG is a set of regulations, not some software library...

It's not that different either. If an organization wants to work with WCAG 2.2, but is legally required to conform to WCAG 2.0, can they do that? With a success criterion removed from 2.2, the answer isn't "obviously, yes" anymore. In many places that will mean lawyers need to get involved, which slows adoption, and who may end up deciding that to minimize risk they can't adopt WCAG 2.2 at all.

@alastc:
We've removed techniques (informative content) previously, why not ACT rules?
Also, how many 4.1.1 rules would be affected? I saw one from a quick scan, but I didn't do a thorough check.

There are two, both of which are implemented in tools. Unlike techniques, ACT rules aren't tied to a specific version. Few WAI resources are. Removing them would remove guidance that is still relevant for the vast majority of people that still use WCAG 2.0 or WCAG 2.1. I don't think that's a good idea.

Some large organisations (with plenty of lawyers) are already stopping their testing of it. I'm not convinced there is a legal problem there. Anything currently required is under 2.1, any future updates to 2.2 change the testing. (Mostly increasing, but decreasing in this one area.)

In last year's EU monitor, every monitoring agency was testing SC 4.1.1. In Europe, conformance to 4.1.1 is legally required, and the governments responsible are not skipping 4.1.1 testing for that.

Even if there weren't legal consequences to stopping 4.1.1 testing, the way you're going about it means in lots of places lawyers are likely going to need to get involved. I think we can, and we should do better than that.

Even though I am in favor of 4.1.1 being removed, I don't care relatively much if it doesn't succeed. Much more important is the adaptation in 4.1.1 for WCAG 2.0 and 2.1:

• test DOM only and not source code
• only test syntactical nesting (Issue2525 parsing syntactical #2793)

This would accomplish a lot: namely, the very nonsense of believing that 4.1.1 improves accessibility (and is included, for example, in EU reports as a frequently unmet SC). If only DOM and syntactical nesting is tested, the only test criterion left is duplicate ID. Here it could be mentioned in the Understanding that this should not be a problem anymore with modern browsers, because according to HTML and ARIA specification the first ID is always taken in case of duplicate ID.

@WilcoFiers The argument that I've found most compelling for why removing 4.1.1 retains backward compatibility with 2.0/2.1 is by keep the impact on end users as the reference point. As I don't believe that there are any issues that impact end users that are not also caught by other SC in WCAG 2.0, a fully conforming 2.2 site would conform to 2.1/2.0 for those meaningful issues.

Of course, there are non-meaningful things that 4.1.1 catches that are not in other SC, and if that is the perspective then it is difficult to argue that there isn't a backward compatibility issue, albeit one that has no end-user impact. I can live with this.

So for ACT rules we probably can't remove rules. We've been deprecating rules, so I imagine ACT will decide to list 4.1.1 rules as deprecated.

There aren't any finalized rules for 4.1.1 in ACT at this time, are there? I see a proposed rule, but please correct me if there are finalized rules for 4.1.1. If not, the Task Force could simply discontinue working on those, based on the impact on users and the potential of the removal in 2.2.

For axe-core, there is some work there, I'm sure. I'm not sure how much, but I will say that the benefit in reduced effort for developers who are saddled with wading through mountains of 4.1.1 issues that either have no user impact or duplicate other results is substantial. I believe that the benefit to the web in general by focusing developers on meaningful results far outstrips the work that companies (e.g., testing companies like Deque as well as enterprises like Adobe, etc.) need to do to adjust their tooling.

There was also a suggestion from @dylanb that naming this WCAG 3.0 would be better but I don't think that has any benefit to your tooling - if you need to invest in tooling improvements to support WCAG 3.0 (where "3.0" is just a text string to your tool) isn't that the same effort needed to support WCAG 2.2 (where "2.2" is just a text string to your tool)? If you need to do work to support this type of change in WCAG, either now or when WCAG 3.0 comes out, it is sort of a wash, isn't it?

Then there's the challenge people who're still using 2.0 and 2.1 face. What are they going to do with a success criterion that is removed from WCAG 2.2? Can they stop testing it? Is that contractually, and legally allowed? Are they going to want to take the risk? Are they now stuck on WCAG 2.0 because the lawyers aren't sure they can use WCAG 2.2 for testing?

It's a good question, but I believe that when the WG makes it clear that the impact on end-users is unaffected by the change and clearly recommends that states that the end-effect of the removal of 4.1.1 is backward compatible for people with disabilities that the legal teams will be comfortable with the level of risk.

If an organization wants to work with WCAG 2.2, but is legally required to conform to WCAG 2.0, can they do that? With a success criterion removed from 2.2, the answer isn't "obviously, yes" anymore.

For me the answer is yes, they can treat the extra SCs in 2.2 as not-legally required, but good to do. They still have to do 4.1.1. I don't think that scenario needs lawyers.

Unlike techniques, ACT rules aren't tied to a specific version. Few WAI resources are. Removing them would remove guidance that is still relevant for the vast majority of people that still use WCAG 2.0 or WCAG 2.1.

Can we not mark them (in the intro) as specific to WCAG 2.0 & 2.1?
In future we should consider versioning for guidelines specific resources. I think the "how to meet" tool does as it can filter on version.

In last year's EU monitor, every monitoring agency was testing SC 4.1.1. In Europe, conformance to 4.1.1 is legally required

And whilst they are using 2.1 that's going to continue. If they update to 2.2, their monitoring would update. Apart from that process taking years (and not something we influence), I'm still not seeing an issue.

the way you're going about it means in lots of places lawyers are likely going to need to get involved.

I haven't seen a reason why that would be the case. The EU regs are based on 2.1. They aren't going to suddenly update that, it will take time. We aren't deleting the 2.1 guidance for 4.1.1.

There will be a far bigger difference by doing what @JAWS-test suggested above, which is to clarify 4.1.1 (via errata) that it is the syntactical only aspects in scope.

And +1 to Andrew's comment above, particularly the last paragraph.

I see a couple views in this thread, 1) removing 4.1.1 creates certain harms, vs 2) but harms aren't created for users or some organizations. Parallel views on deprecating seem to be 1a) deprecating is preferable as an intermediate step to mitigate some confusions, vs 2a) deprecating doesn't do anything practically different from removal.

Based on this I lean towards deprecating as the appropriate step. While deprecating seems unnecessary and unhelpful to some, it also seems non-harmful and not practically different in most cases from removal. Given that others see harm from removing, I think deprecating is the safer choice.

Deprecating would also mean we have to adjust the conformance model, it doesn't cover deprecation.

Presumably we'd have to add something like:

For Level A conformance (the minimum level of conformance), the Web page satisfies all the Level A Success Criteria that are not deprecated, or a conforming alternate version is provided.

Personally, I think that removal is less confusing that deprecation. Our audience isn't only software developers, including something but saying "you don't need to do that one" is odd.

Based on this I lean towards deprecating as the appropriate step.

@michael-n-cooper Can you clarify the actual difference between these two options?

Another option that the WG has is to publish a revised recommendation - we could pursue a revision for all 2.x versions to remove 4.1.1 entirely. That would avoid any backward compatibility issues, and once the EN is updated they could remove 4.1.1 from there also.

I created a pull request as a possible alternative to removing the SC: https://github.com/w3c/wcag/pull/2823/files

There are definitely other ways we can avoid the issues I've raised, but I'm curious to hear what people think of that direction.

Personally, I don't see any difference in practice. On the face of the spec I think it is harder to understand.

Identifying it as obsolete and providing documentation as to why, works for me (and TPGi)
Need to provide definition as to what obsolete means in context of a WCAG SC

The argument that I've found most compelling for why removing 4.1.1 retains backward compatibility with 2.0/2.1 is by keep the impact on end users as the reference point. As I don't believe that there are any issues that impact end users that are not also caught by other SC in WCAG 2.0, a fully conforming 2.2 site would conform to 2.1/2.0 for those meaningful issues.

This is only correct if you add an erratum to WCAG 2.0 and WCAG 2.1 to clarify that "elements are nested according to their specifications" refers only to syntactical nesting and not to the validation of content models. Otherwise, deprecating SC 4.1.1 in WCAG 2.2 will give the (false but real) impression that the validation of content models is being removed. The claim that this has no impact on accessibilty is a bit harder to maintain with the content model interpretation than with the (originally intended) syntactical interpretation.

I haven't seen a reason why that would be the case. The EU regs are based on 2.1. They aren't going to suddenly update that, it will take time. We aren't deleting the 2.1 guidance for 4.1.1.

Just to be pedantic, EU regulations aren't based on any version of WCAG because the W3C is not recognised as an official standards body by the EU. Hence, the regulations don't need to be updated when a new version of WCAG is published. What the EU does is get EN 301 548 updated and then announce in its official journal which version of that standard is now the "harmonised European standard" for the purpose of the Web Accessibility Directive.

The next big deadline for accessibility in the EU is June 2025, when the "European Accessibility Act" comes into force. EN 301 549 will be only one of the standard relevant to that EU directive (others will be created following an EU mandate). If WCAG 2.2 is finished by, say, the summer of 2024, that should give the European standardisation bodies enough time to update EN 301 549 and for the EU to acknowledge that version in its official journal before June 2025.

Another option that the WG has is to publish a revised recommendation - we could pursue a revision for all 2.x versions to remove 4.1.1 entirely. That would avoid any backward compatibility issues, and once the EN is updated they could remove 4.1.1 from there also.

I don't know whether revision all 2.x versions is necessary. I doubt that this would be necessary for EN 301 549. Chapter 9, for web content, contains lots of requirements that say "Void". This is currently the case for all level AAA success criteria, to keep the numbering of requirements in the EN consistent with the numbering in WCAG. (E.g. SC 2.1.1 in WCAG matches requirement 9.2.1.1 in the EN.) There are even more instances of "Void" in chapters 10 (Non-web documents) and 11 (Software) because certain WCAG success criteria don't apply outside the web (e.g. SC 2.4.1: Bypass blocks). I think that a future version of EN 301 549 that is updated to reflect WCAG 2.2 could perfectly say "Void" for a deprecated or removed SC 4.1.1.

Need to provide definition as to what obsolete means in context of a WCAG SC

Indeed. The W3C Process Document defines "obsolete" only for entire specifications, not specific requirements within a specification.

One way of representing this in WCAG 2.2, partly inspired by EN 301 549, would be to keep the number in the spec and rename the SC as "Success Criterion 4.1.1 Parsing (Void)". Below it, there would be a note explaining that the SC is no longer part of WCAG 2.2. "Understanding Success Criterion 4.1.1: Parsing (void)" could then explain why the SC is no longer in WCAG 2.2. Plenty of arguments have been provided in comments on issue #2525. (Whether these arguments are sufficient is not something I wanted to bring up here.)

Indeed. The W3C Process Document defines "obsolete" only for entire specifications, not specific requirements within a specification.

Not exactly. The process document indicates:
"To rescind, supersede, or obsolete some part of a Recommendation, W3C follows the process for modifying a Recommendation."

This would be the process to remove 4.1.1 from 2.0 and 2.1. However, your point is correct in that the process document doesn't seem to have any text regarding the marking of a criterion that has been part of a previous version of a spec obsolete in an updated version. Probably because there is no expectation in the process document that new versions of specs must include all aspects of previous versions - this is a WG expectation.

I think the last points from @awk and @GreggVan are both correct, Gregg outlined what I remember learning when I joined the group, and that has been interpreted to be 'must include everything' by some.

I also wanted to pick up on:

I was under the impression WCAG was using semantic versioning

I think WCAG 2.0 came out before semantic versioning was defined in that way (2009ish), and 1.0 definitely did.

But more importantly, it really isn't a software library. People don't import it into their projects automatically and suddenly find things break if we remove something.

The versions are several years apart, and it is up to other organisations / states / regulators whether and when to update, not us. WCAG 2.1 was 'recommended' in 2018, and some people are still on 2.0. It is not in any way "short notice".

The key is what Andrew & Gregg outlined about it not being a weaker requirement in 2.2 compared to previous versions, and I've not seen anyone arguing that.

I've also not seen Patrick's comment tackled:

... I fail to follow. So you mean it's there, but an automatic Pass? Is that any better/more logical? How does that help in the scenario you raise about "people who're still using 2.0 and 2.1"? How does that help "organizations [that] have resources [...] for different versions of WCAG 2"? what, materially, makes deprecation/auto-pass versus removal better?

In a regulation - marking it obsolete would remove it from this regulation - and would remove it from past regulations through an update (since it no longer mades sense to require it)

I love it.

Many brands try to do the right thing. Marking something as obsolete in 2.2 but keeping it for 2.0 and 2.1, especially from a legal perspective, in my opinion doesn't make sense.
I think our main goal should be help users with disabilities, ensuring that guidelines are meaningful and up to date, reflecting real needs. To do so we should also help authors (and for big companies authors means everyone involve into the process, which is already not easy) providing clear instructions.
The DOT for example requires compliancy with WCAG 2.0.
In my opinion we cannot say:
"hey, we realized that 4.1.1 is no longer required nowadays as it refers to the syntactical aspect and not the content model; this is already managed by browsers/UA rules, and other relevant items are already covered by other criteria.
That said, if you have to meet WCAG 2.0 AA, it's still a requirement."

If we realized it is not needed, why it's still a requirement for someone?

if we mark it as "Obsolete": - we should also mark it as "removed" (" 4.1.1 This SC is obsolete and has been removed".

I think that is the main difference: Should the SC text be removed from the face of the spec?

I don't mind if it is marked as obsolete or not, so long as the SC text is not there. That makes it crystal clear it is not required in 2.2.

Regarding 2.0/2.1, I'm less certain. My default perspective was that they are of their time, why change them? People can change practices when they update to use the newer version.

4.1.1 was useful when 2.0 was released, it is primarily the browsers that have changed that makes it redundant.

If we realized it is not needed, why it's still a requirement for someone?

Doesn't that cause issues for people who have written 2.0/2.1 into their regs? (E.g. Section 508, EN 549 301). If not, happy to do so, but that's the sort of change that might create more problems than just have a clear update path.

However, this isnt really the case. People still user 2.0 and 2.1 today — so this guidelines solves no problem that exists today - but still causes problems. So I believe it should be marked as obsolete and removed from older versions as well — since they are still being actively used.

To me, that sounds like pulling the carpet from underneath someone's feet.

To me, that sounds like pulling the carpet from underneath someone's feet.

Except that when this carpet is removed they don't fall, they discover that the floor feels exactly the same as it did when the carpet was there, and they don't have someone telling them about every crumb or speck of dust on the carpet... :)

Of these choices:

rescind, supersede, or obsolete

Only rescind comes close. Neither supersede nor obsolete is strong enough. 4.1.1 is harmful, maybe not as counterproductive as WCAG 1.0 Checkpoint 6.1 (with the benefit of hindsight) but it is bad.

Best case, 4.1.1 is entirely redundant. The actual errors it catches fail other SC. That's not so terrible, but is contrary to a litmus test for new SC, that they catch problems missed by all other SC.

Fake errors are insidious. It is a distracting waste of resources. Pretend errors harm the reputation of the whole standard, when really it is just the one SC outliving its usefulness.

It is too easy for 4.1.1 to be a tool for bad actors. Since fails against 4.1.1 are unambiguous from a code-inspection perspective, it promotes litigation at the cost of actual improvements to accessibility.

Ref: https://lists.w3.org/Archives/Public/w3c-wai-gl/2022OctDec/0198.html

There aren't any finalized rules for 4.1.1 in ACT at this time, are there? I see a proposed rule, but please correct me if there are finalized rules for 4.1.1. If not, the Task Force could simply discontinue working on those, based on the impact on users and the potential of the removal in 2.2.

Two proposed rules so far:

• Attribute is not duplicated is only implemented by a linter and, in the light of the recent discussions, is probably not even a 4.1.1 failure and never was 😖 (browsers fix it and parsing works). We should probably deprecate it or make it a best practice only.
• Id attribute value is unique is consitently implemented by all 5 major implementers of ACT rules. From the look of it, the ACT TF should probably review and publish it soon (if not for this full discussion).

If an organization wants to work with WCAG 2.2, but is legally required to conform to WCAG 2.0, can they do that? With a success criterion removed from 2.2, the answer isn't "obviously, yes" anymore. In many places that will mean lawyers need to get involved, which slows adoption, and who may end up deciding that to minimize risk they can't adopt WCAG 2.2 at all.

If I understand this correctly, your point is that removing somewhat obfuscate the fact that conforming to "2.0 + 2.2" is possible (and lawyers would defensively say that 2.0 is the requirement so don't take risks); while deprecating/obsoleting/… makes it more obvious that it is.
That might be something we can address with a note making clear it is possible.

As a tool vendor, I do not have any problem with the removal of the SC.
Alfa will keep mapping "id is unique" to 4.1.1 and record in its modelling of WCAG that 4.1.1 only exists in 2.0 and 2.1. When selecting rules by WCAG version + level, users will automatically get the correct ruleset and more advanced users can still manually add the rule to a 2.2 ruleset.
As for our platform, we'll probably list the rule as a best practice by default (I find it very useful to point at when customers ask why some <label for="foo">Foo</label><input id="foo" /> is flagged, as mentioned, this fails another SC but boils down to a duplicate foo id). Then, we have ways to customise the rules that we show to each customers, and will likely provide sensible default rulesets. We'll need to add a bit of logic to report it as "level A" or "best practice", but that is not different from 2.4.7 changing level…

Overall, I'm rather in favour of removing the text of 4.1.1 from the normative document. As mentioned, keeping it, even as "deprecated", can be fairly confusing for less technical/development minded people, and they are many in the field. Making it crystal clear in the note that it is possible to satisfy WCAG 2.2 + SC 4.1.1 can ease the mind of lawyers looking at it without technical knowledge. But keeping it while saying "by the way, you can ignore it" might create even more confusion than it solves.

As for the major/minor versioning, I think the backward compatibility we need to ensure is for end-users (people with disabilities), not at the "API" granularity (SC). We're already breaking the "API backward compatibility" by changing the level of 2.4.7.

I think the important backward compatibility property we need to maintain is in the line of "it is possible to satisfy level [A/AA/AAA] of all minor versions together" (which is of course true for the additive changes between 2.0 and 2.1). Here, it is possible to satisfy level A of 2.0 + 2.1 + 2.2 together (same with levels AA or AAA), so we can keep that as a 2.x version. If we introduce a change that make it impossible to satisfy both 2.x and the new change, then we should probably bump the "major" version number.
By keeping this property (and, likely, making it explicit in the "comparison with 2.1" Section 🤔), we tell organisations that they can adopt 2.x while still maintaining legal conformance to 2.0. This obviously requires more work (from them) than simply conforming to either 2.0 or 2.2, but it is a voluntarily choice of their own anyway.

Closing due to CFC: https://lists.w3.org/Archives/Public/w3c-wai-gl/2023JanMar/0097.html