Repository navigation
Do not remove 4.1.1 Parsing from WCAG 2.2 #2820
Description
Activity
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.
Reacted by Joppe Kroon, mmeller75, Corey Moore, seanbeld and FUFUFETThe 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.
Reacted by Oyama MichinokuReacted by Joppe KroonIf 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?
Reacted by Scott O'Hara and JAWS-test- changed the title
[-]Do not remove 4.1.1 Parsing from WCAG 2.2[/-][+]Deprecate rather than remove 4.1.1 Parsing from WCAG 2.2[/+]on Dec 1, 2022 - changed the title
[-]Deprecate rather than remove 4.1.1 Parsing from WCAG 2.2[/-][+]Do not remove 4.1.1 Parsing from WCAG 2.2[/+]on Dec 1, 2022 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.
Reacted by Corey Moore and seanbeldWCAG 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.
Reacted by Corey MooreEven 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 - changes to 4.1.1 normative (obsolete) and understanding #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.
Reacted by Wilco Fiers13 remaining items
- On Dec 7, 2022, at 5:50 PM, Alastair Campbell ***@***.***> wrote: I've also not seen Patrick's comment <#2820 (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?Well, the question of passing would not come up if we do this right - and clearly. if we mark it as "Obsolete": - we should also mark it as "removed" (" 4.1.1 This SC is obsolete and has been removed". Otherwise it will be very confusing and lead to no end of different interpretations. It should also have a note below it 1) saying why it was removed. 2) saying what the effect on older standards is. WHAT SHOULD THE EFFECT ON OLDER VERSIONS BE? - In voluntary standards - marking something obsolete would remove it from this one (or recommend it not be used) - 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) WCAG is a strange fellow in that it is a voluntary standard that (unlike most or all other W3 standards) is regularly changed into a regulation. So I would think we would follow the pattern of regulations. If we mark it obsolete and removed in 2.2 - we should by errata, and later edit, go back and mark it as obsolete and removed in 2.1 and 2.0. Anyone who passed the provision 2.0 and 2.1 in the past, would pass 2.2 of course. but anyone using 2.1 and 2.0 going forward would no longer have to do something that no longer has any meaning. gregg…Reacted by Scott O'HaraReacted by Giacomo Petri
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.
Reacted by Shadi Abou-Zahra- This would be ok if those guidelines (2.0 and 2.1) were only used in the past and are basically archival. 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. best gregg…On Dec 8, 2022, at 5:07 AM, Alastair Campbell ***@***.***> wrote: 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. — Reply to this email directly, view it on GitHub <#2820 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXTGEAIGWW7J2E23743WMHMPJANCNFSM6AAAAAASQATURI>. You are receiving this because you were mentioned.
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... :)
Reacted by Scott O'Hara and Giacomo PetriReacted by Alastair CampbellReacted by Patrick H. Lauke- What carpet and whose feet? Although there was benefit a decade ago — there is no benefit to anyone today - yet people are using WCAG 2.0 and 2.1 to evaluate sites today. By removing it from the old guidelines - it looks to me like we are just saving a lot of people a lot of time checking for something that is not needed and solves no problem that exists today. Am I missing something? Thanks…On Dec 9, 2022, at 1:01 AM, Christophe Strobbe ***@***.***> wrote: 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. — Reply to this email directly, view it on GitHub <#2820 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXQSVH4DOEOUDIAH5GTWMLYOXANCNFSM6AAAAAASQATURI>. You are receiving this because you were mentioned.
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.
Reacted by Scott O'Hara, Chris Keroack and Manuel Razzari- To me, that sounds like pulling the carpet from underneath someone's feet.What carpet and whose feet? There is no benefit to anyone today. We are not going back in time to when it was a problem and removing it then. It was there when it was needed. But people are still using 2.0 and 2.1 so by removing it from those old ones we are just saving a lot of people a lot of time checking for something that provides no benefit today…On Dec 9, 2022, at 1:01 AM, Christophe Strobbe ***@***.***> wrote: 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. — Reply to this email directly, view it on GitHub <#2820 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXQSVH4DOEOUDIAH5GTWMLYOXANCNFSM6AAAAAASQATURI>. You are receiving this because you were mentioned.
- I might agree with your thought - if the SC wasn’t causing confusion and lost time by evaluators and authors — with no benefit to people with disabilities anymore. But I’m not sure I follow the logic of keeping a guideline that confuses people and solves no problem. No one writes AT code that way anymore. It is brittle and actually is like hacking instead of using APIs. There is no reason to think that we will ever go back to that. And keeping a guideline because someday someone may use bad programming practice ( and try to read the code directly ) doesnt seem to be a good use of space in WCAG and certainly not a good use of time by evaluators or web authors. It was level A for a reason that was true in the 2000s but is no long true. There is no reported problem anywhere from any AT that this solves. AT now gets its Informtion in a better, more stable, and much easier fashion. And I don’t see any reason to suspect that will change. Am I missing something you are aware or thinking of specifically?…On Dec 12, 2022, at 3:56 PM, sboptum ***@***.***> wrote: I have to agree with Wilco on this one. Unless you have a good grasp of the impact of removing Parsing on all forms of current assistive tech, (not to mention future tech) this is entirely short-sighted. I can easily imagine a future scenario where the wild west of invalid html requires W3C to re-add Parsing in the next WCAG version/update. Start and end tags, proper nesting, etc. are fundamental -- you simply cannot know with any reasonable certainty that a "minor" parsing error does not affect some form of assistive tech either now or in the future. This is Level A for a reason. — Reply to this email directly, view it on GitHub <#2820 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXRKNLHZD4KNPXSZUGTWM63STANCNFSM6AAAAAASQATURI>. You are receiving this because you were mentioned.Reacted by JAWS-test and Chris Keroack
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 duplicatefooid). 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
Since I wasn't able to make it to the call in which this was discussed, I wanted to raise the issue here. I have strong concerns with removing SC 4.1.1 Parsing in WCAG 2.2. Removing this SC creates a major discrepancy with prior versions of WCAG 2. This results in a lot of (largely unnecessary) difficulties for adopting WCAG 2.2, and raises complicated questions for people still on WCAG 2.0 or 2.1.
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. If SC 4.1.1 is removed, for all those thousands of resources a decision will now need to be made on how to handle this removed criterion. Do you remove it from the resource, and so removing it from WCAG 2.0 and 2.1? Do you leave it in, and so basically ignore it was removed from WCAG 2.2? Do you insist on readers/users selecting a version so you can switch things out? Do you try to add clarifying text? If so, what do you call a criterion that is removed in one version, but not others?
Because WCAG 2 is designed to be additive, nobody built / wrote things to allow success criteria to get removed. There are multiple projects I am personally involved with that are not able to handle this change without some significant rethinking and costly changes that need to be made. I won't be the only one, but here's how this is going to impact me:
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. But then is it clear that one place on the W3C says 4.1.1 is removed, and another says resources related to it are deprecated? For axe-core the way conformance levels is done simply doesn't allow for rules to be turned off when a certain level is set. Changing that would be very costly. Probably not worth the investment for a one-off scenario. No clue what we'll do instead though.
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?
What's being proposed is almost a textbook example of a breaking change. This is costly, will create a lot of confusion, will result in inconsistencies and splintering, etc.
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. 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.