It's interesting how I often hear within accessibility conversations, that it's not a technical issue. However, this situation does remind me of the concept of technical debt.

If we keep moving forward while leaving many people behind, WCAG is not being inclusive. There's a gap between those who write, and those who (are expected to) follow.

The W3C isn't an educational institute. There are lots of organisations that are. The W3C certainly has some responsibility in ensuring people know how to use its standards. But there is only one organisation that can write updates to WCAG, and there are tons of organisation that can, and are busy training people on those standards.

@WilcoFiers good point and angle of approach (to think about) Wilco!

But there is room for providing more proper examples for the documentation to more clearly explain what a SC covers (and what not) so we have less ambiguity.

I see that even the professional organizations (NOT ALL!) struggle to understand the wording and what it exactly covers, resulting in teaching just off the mark

The W3C certainly has some responsibility in ensuring people know how to use its standards. But there is only one organisation that can write updates to WCAG, and there are tons of organisation that can, and are busy training people on those standards.

clearly there's a middle ground though. otherwise this comes off a bit as "it's ok if the spec is vague, if we have lots of commercial organisations that can then charge developers to explain what it means"

surely WCAG itself (and other guidance) should be as accessible as possible, including how the content is written. If it helps, related thread here: https://twitter.com/joelanman/status/1388215541467320326

update - twitter thread lost presumably due to twitter exodus

The W3C isn't an educational institute. There are lots of organisations that are. The W3C certainly has some responsibility in ensuring people know how to use its standards. But there is only one organisation that can write updates to WCAG, and there are tons of organisation that can, and are busy training people on those standards.

Exactly, the W3C has some responsibility. I think the issue is that if there's a balance between the W3C and other organizations, then that balance is off right now.

@WilcoFiers wrote:

there are tons of organization that can, and are busy training people on those standards.

True, for all companies who can afford it AND have budget for it (often very, very expensive!), all others are dependent on 'free available resources', probably the majority in the world

It is my personal opinion that we cannot hold back the rights of people with disabilities to equitably access information order to spent an undetermined about of time on re-writing documentation. I agree we should focus on agreeing on clarifying interpretation of 2.0,2.1, and 2.2 after 2.2 comes out but we also need to focus on WCAG 3. Technology continues to change and the guidelines cannot simply stay as they are as we will lose a generation of access.

In terms of specifics in the article - suggesting that the reason the web is not accessible is because of the resources that this volunteer community provides is disheartening to those who have volunteered are time to try and clarify the guidelines. In my the local community the biggest challenge with equitable access as a person with a disability is not the resources - it's the unconscious bias of people in my community who have specifically stated that since their white, non-disabled family has not experience discriminations or any sort of inaccessibility therefore it does not exist and no action needs to be taken to address something that isn't a problem. Thus, creating an inclusive culture where people are taught to understand and respect the differences and diversity of humanity is a critical piece that must be addressed.

Regarding the WebAIM survey, Just because 99% of webpages have detectable errors also doesn't mean the pages are not usable although we know that many parts of the web are not usable by people with disabilities. The challenges are complex and are not limited to training - tooling, time, budget, 3rd party frameworks and a whole host of other issues impacting accessibility of the web.

While there are absolutely work that should be done to ensure old materials do not show up in search results - valid techniques will and should continue to show up and preventing certain valid techniques from showing up is likely out of control of the group. Even when a disclaimer and warning is provided the article suggests that developers just copy and paste without reading it - that is something that really can't be solved by the documentation. If we provide materials showing the best solutions and then warn people about less optimal solutions but they choose to skip past the warning and copy and paste anyway - there is little we can do. I'm also sure that good developers would be taken aback by this assertion that they simply copy and paste and don't understand the code they are using.

In summary, while there is much work to be done - this is a volunteer effort and everyone who thinks something should be done should help out to make it better. Many of us have sacrificed relationships with our family and children to make these materials better and to provide a set of guidelines that will increase access to the web to the largest group of people - there is not some deep pocketed corporation funding this effort where people are paid to just write the guidelines and materials. Perhaps there are more ways that we can involve those in the community to contribute by removing barriers to participation.

On the original topic, there are a couple of things in progress that should help:

1. The re-design work that Hidde has been doing on the informative docs that makes clearer whether something is the most recent version, and generally improves the readability.
2. Getting some canonical URL meta-data into the old docs, pointing to the newer ones. That should reduce the old docs turning up in search engines.

But there is room for providing more proper examples for the documentation to more clearly explain what a SC covers (and what not) so we have less ambiguity.

As I mentioned in email, there is a tension:

We need to consider that if we try and explain every scenario and show lots of (code) examples, the docs get longer and it is more likely that we create conflicts in the documentation, which again makes it harder to maintain. There is probably a rule similar to “as simple as possible but no simpler”, e.g. “as concise as possible but not overly concise”.

Another issue is that no-one knows everything about every SC. I don’t think that’s due to our docs, it is just that accessibility (combined with design & web-dev) is an incredibly wide subject. Therefore when someone focuses on one aspect of one SC, it is easy to miss how it interacts with other SCs. Those “simple fixes” may not be as simple as they appear when you take in the bigger picture. (That's why the review process is so valuable, you get the bigger picture perspective. Eventually.)

Another consideration is that many of the techniques do appear dated, and they aren’t what we would consider best practice. However, they are still valid techniques. There are some scenarios where they are valid and/or best to use. I’m not sure how (or whether) we can solve the problem of “developers just google it and copy the first code they find”, apart from removing code examples?!

(Not in the email:) It is worth realising that the WCAG documentation is essentially an open-source project with a particular governance structure. Anyone can contribute, but only a handful of people do.
Perhaps if we can create (and agree) a process and guidance for updating techniques, we would get more participation? (Any other ideas?)

Finally, we do have to be cognisant of how a group in the W3C operates. A quick overview of some pertinent bits are:

• The group agrees what it wants to work on.
• That 'charter' has to be agreed by the whole W3C membership.
• The group needs to stick to the deadlines (or have good reasons for slippage)

We were chartered to deliver WCAG 2.2 in the timeline of this charter, so that has been a priority. We can't just stop that and work on something else.

However, we can and should carry on making updates to the informative documentation. I have been stacking issues into a survey for the group meeting, and we are dedicating 30-60 minutes of the meetings to that. Now that 2.2 is out for review, we have the space to focus on that.

suggesting that the reason the web is not accessible is because of the resources that this volunteer community provides is disheartening

Indeed, in training sessions I find only about 10% of people have even opened the guidelines, most were unaware. And +1 to the rest of Jon's comments.

Perhaps if we can create (and agree) a process and guidance for updating techniques, we would get more participation?

Personally, as someone who regularly contributes to open-source projects, I really like this idea. Even though the documentation is in GitHub, it’s unclear which parts of the repository (if any) are open for contributions beyond feedback and correcting typos.

Apart from the documentation, it would also be good to know whether any of the documentation site templates would be open for contributions.

The success of WCAG is in part that W3C invested (a little) into education and that it was always a part of it. And that is the issue. Can we squander the reputation of the education material and make it even more confusing? One of the biggest arguments against following WCAG that I hear is that it is too hard to understand and that the “supporting documents” are not straightforward to understand or even to find.

• Just last week, someone cited a WCAG WG Wiki page with a question because they were confused and thought it was official errata. (It was only a brainstorming.)
• Just today, a client asked for advice on underlining links in text. They had heard that underlining it was only necessary on hover and focus. And I had to go into the backstory of how the WCAG WG came to the decision to allow it in a non-normative document. And that the normative document is not specifying the exception and also on touch screens it is not accessibility supported because of the lack of hover/focus.
• Almost every week, I stumble about something that is unclearly defined in the spec, or looks differently, or has a different name. I know where to seek clarification, and often I get something that vaguely resembles that. But sometimes issues stay open for months with barely any movement.

And the group has always the eyes on the new and shiny. Now it is WCAG 2.2, then it is WCAG 3. Because just “polishing the material and clarifying the SCs” is not deemed charter-worthy. Because W3C is not set up for it because, to quote Wilco, “W3C is not an educational institute.”

I’ve argued for a long time that W3C needs to realize that it is that. Especially for accessibility. But also for other specs. That there is barely an editorial process to fine tune and clarify SCs, once they have been agreed on, shows. When you scratch the surface, as someone who has not been involved, it collapses like a Soufflé in the oven.

The Working Group barely manages to keep one version of the Guidelines with the supporting materials maintained. Now that we have two, soon three, versions of the same standard, the seams are very apparent. This will only get worse with a fourth version of WCAG 2 or with a whole new concurrent WCAG 3 standard.

This is not to be discouraging. People have critique because they care. Because they want WCAG to be better because they want accessibility to be easier.

The WCAG effort seems incredibly under-staffed (there should be a dedicated team contact for WCAG 2 and one for WCAG 3, for example). The strategy for educational material needs to be unified with a clear vision to overhaul everything and a dedication to bring the findings from education back to the group. Only this feedback loop can tangibly improve the success criteria and the spec. How is the working group supposed to improve writing SCs when the feedback loop is missing that says, “this SC is super hard to explain”? And on the other hand such comments cannot be dismissed by the Working Group.

WCAG needs and deserves the support. It is too important that any of it is an unreliable state. And yeah, you can argue that it’s just “a bit of disarray in the non-normative documents”, but nobody outside this circle knows the difference. Nor should they need to know. Many want to help but do not feel welcome. Many don’t even know they can.

An accessible WCAG is a better, more useful, WCAG and I think we (=the accessibility community, AG WG, WAI and W3C) can do it.

I feel a need to tackle something from the article, otherwise we can't progress this aspect. Where the conclusion starts off:

Make the W3C specifications and documentation accessible to web creators, unambiguous and easier to maintain.

That is a laudable goal, but in practice it becomes self-contradictory. I've said previously: "A guideline can be easy to understand, easy to test, or short. Pick any two."

I'm equating "accessible to web creators" as easy to understand, and "unambiguous" as easy to test. If we meet those goals the guidelines will get longer because you simply can't be both without expanding a lot. Expanding then means harder to maintain because there is more of it.
(Seriously, it's a good exercise: Pick any success criteria. If you make it easier to understand, it will get longer or less accurate. Except "Language of the page", which is the exception to prove the rule.)

In WCAG 3.0 I think (although it's not settled) the testable statements aspect is getting longer and easier to understand. So it takes a different approach, which is currently open for iteration.

For WCAG 2.x, I think the best approach is to improve the understanding documents. There was an issue somewhere (hard to search for) that proposed doing a "What this covers, what this doesn't cover" paragraph at the top of each Understanding page. That seems like a good place to start.

And working through the backlog, obviously.

@alastc this one?

#744

The re-design work that Hidde [with EOWG] has been doing on the informative docs that makes clearer whether something is the most recent version, and generally improves the readability.

more info:

• Requirements analysis with user analysis
• Current user flows
• in-progress prototypes

it would also be good to know whether any of the documentation site templates would be open for contributions.

@thibaudcolas Yes! Accessibility Education and Outreach Working Group (EOWG) is working on them right now (for AG WG approval). Feel free to contact me directly if you want guidance on contributing (shawn@w3.org)

It is worth realising that the WCAG documentation is essentially an open-source project with a particular governance structure. Anyone can contribute, but only a handful of people do.
Perhaps if we can create (and agree) a process and guidance for updating techniques, we would get more participation? (Any other ideas?)

just going to pick up on this point: yes, it's an open-source project. and yes, the threshold to contribution is a lot lower now since WCAG moved over to using github, and working far more openly (to an extent anyway, some decisions still happen in smoky backrooms, or only if you have the time/ability to take part and follow 2+ hour voice calls each week ... but I digress). but with the increased openness - anybody can file an issue or, if they can work out how the spec is actually put together on a technical level behind the scenes with magic XSLT stuff, contribute changes/additions/new techniques/etc. but what I think wasn't taken into account when WCAG's working model was opened up to github is: there'll be a lot more incoming "stuff" that needs to be reviewed.

Back in the old days of "everything just happens at a slow pace over the mailing list, and only a few tech savvy people can actually make changes to the files themselves", it was likely much easier. Now, there's understandably much more work involved in just triaging and sifting through contributions...and perhaps there's not been a sufficiently robust process of how to swiftly - dare I say "in an agile way" - deal with these to avoid having them pile up.

Yes, some contributions/PRs will be very naive and will have repercussions that the person submitting it may not have thought through. These will require careful review and discussion. Other contributions/PRs will be absolutely trivial. For the most part, both types of contributions now seem to just pile up and create a logjam, possibly because they are often treated the same ("need to find time to discuss this in the voice call at some point"). When, quite possibly, the simpler/more trivial ones could be processed in a speedier way, leaving more time to then consider the trickier ones. And perhaps, regardless of other topics, making it a standing item for each week to spend some time triaging incoming issues and PRs.

Yes, this will be more admin overhead. But I think at least partially moving towards something like this will help at least keep our head above water with the influx of new issues/PRs (and keeping in mind that the vast majority of these issues/PRs are currently generated mostly by people in the actual working group ... we're not even at the stage where people from the wider community submit lots of materials. if there's already a sense of an overwhelming backlog NOW, imagine how it will be once the "this is an open source project, so ... feel free to file an issue/PR" answer is taken up by the community and they do submit lots of stuff - for WCAG 2.x, and for WCAG 3.x, and ...)

As long as there is a gatekeeping group that operates on the W3C process for these additional materials, contribution is much harder than to typical Open Source Projects. I see the same things with EOWG resources where every little contribution is scrutinized. WCAG is a tiny project in scope compared to other open source projects, yet addressing issues and merging in PRs is at a glacial pace.

Even I, an annoying stickler, only open issues for the top 1% of things I stumble over, because I think they are important enough to go through the process. And even then it’s “I better say something even though I know it will likely go nowhere because otherwise I would have a bad conscience because I haven’t said something.” I contribute because I see it as a duty to do so, not because it is particular fun to do it or because I think I have an impact.

One thing that makes me uneasy about the general statement of getting the old stuff understandable before adding new stuff, is that the old stuff has these holes where real users with real disabilities are simply not mentioned, as if they don't exist. And these new SCs being piled on are meant to address those.

I can't see it being better to stick to a linear process of improving the old before adding the new, because I see adding the new as partially addressing the old. Looking at the changes for focus visibility, this is clearly because the old had in many cases too many loopholes, like Patrick's famous "focus visibility passes if you visually expose a single, sufficiently-contrasted pixel on a focussed element" example. Which is why there's now a new proposal I still can't quite wrap my head around because I can't math but is trying to address that focus needs to be practically visible.

But with the ever-present pressure of the law hitting WCAG from the other end, I'm wondering if the judiciary idea of "the reasonable man" will ever find a place in the Understanding Docs. This principle would wipe out a single pixel from being sufficient, or would look at Eric's example of "link colours are at least 3:1 contrast from non-link colours" where no "reasonable man" character would agree the links were findable for anyone.
Perhaps such a concept could help editors decide how much explanation of edge cases is necessary to help that balance between "understandable" and "strict enough to be testable", I dunno.

@rianrietveld We've found that to help colleagues at the Co-op in the UK we needed to attempt to write the guidelines in plain English. You might find our approach interesting: coop.co.uk/accessibility/standards

I'm very grateful for all of the excellent work people have done on WCAG, but I would say that my universal experience from working in digital teams for a long time is that people find it very hard to navigate and understand. And that's without taking into account cognitive disabilities, so I fully agree with @yatil's points. Again from my experience of working in multi-disciplinary teams is the way to achieve that is through greater involvement/empowerment of content designers and user researchers. GOV.UK is generally accepted as a success story in making important, complex content accessible.

Just hopping in to say that the old stuff is still in part nearly incomprehensible for me. I really try hard to understand the reasoning to make my HTML really accessible and to understand what is required to fulfil the criteria. At the company this feels like bible exegesis as we come up with different interpretations.

As a good start I suggest to remove all the techniques that were good practice for any Internet Explorer 11 and below. Or at least mark the techniques as dated or deprecated.

One of the rules for inclusive web sites is easy language. The WCAG content is in every respect a complete disaster.

Sidenote: the best practice examples are only partly helpful either. We copy pasted one of them and I was told that the result was unusable in Voice Over. But still they are the only WCAG documents I suggest for devs that do not have the time to read a document written in a language for lawyers that is not their first language.

But like joelanman I appreciate all the work that has been put into the various documents.

Oh, I like this idea:

Or at least mark the techniques as dated or deprecated.

There are reasons why WCAG authors do not want to remove Techniques, such as that websites which used a Technique in the past which was considered Sufficient would sort of have the rug pulled out from under them (and websites lose maintainers/don't get updated).

However having those techniques marked with a "this is no longer a recommended practice" type thing would allow new readers to know to avoid those techniques while not making some ancient website suddenly seem to not conform.

There are reasons why WCAG authors do not want to remove Techniques, such as that websites which used a Technique in the past which was considered Sufficient would sort of have the rug pulled out from under them (and websites lose maintainers/don't get updated).

but techniques are only examples of how an SC's requirements can be met. sites can fulfill the normative requirement of an SC any way they want, even if there's no documented technique that matches what they're doing, as long as they still do what the SC itself asks. techniques are not comprehensive - they don't cover every possible scenario. having a technique that a site used "disappear" does not invalidate the pass/fail of a site that used that particular technique in the past.

having a technique that a site used "disappear" does not invalidate the pass/fail of a site that used that particular technique in the past.

And if it would, that technique has not been a valid technique regardless of it being listed as a WCAG technique or not. (That said, I think that all WCAG 2.0 techniques should be frozen in time, with clear visible notifications to use the 2.1 documentation instead. The same should happen with 2.1 techniques once 2.2 techniques are introduced. It is not helpful to have multiple versions of the same information online. Search engines should be redirected to new techniques. Users also after a grace period.)

techniques should have a prominent "created / last reviewed" kind of info. and yes, for each major new version of the guidelines, would have been good in hindsight to do a thorough review / refresh...

Thank you all so much for taking my concerns seriously and discussing how to improve the docs and workflow. I'm really grateful for this. 🙏

having a technique that a site used "disappear" does not invalidate the pass/fail of a site that used that particular technique in the past.

Then why was there so much pushback about removing the sufficient technique of distinguishing links from non-links by merely having a 3:1 contrast difference between link colour and text colour? If all this time it could have easily been simply removed as a sufficient technique??

Because that was a cheeky submarine escape clause that in the end was called out and the "it's not just color (hue), but brightness/lightness too, which is not color" was added to the understanding doc for use of color. it was a handwave, a fudge, that needed to remain somewhere otherwise half the internet would retrospectively fail overnight...

having a technique that a site used "disappear" does not invalidate the pass/fail of a site that used that particular technique in the past.

Then why was there so much pushback about removing the sufficient technique of distinguishing links from non-links by merely having a 3:1 contrast difference between link colour and text colour? If all this time it could have easily been simply removed as a sufficient technique??

Because it was decided that the technique (G183) is used to clarify that color in 1.4.1 Use of Color means hue, not color (which traditionally consists of hue, saturation, and lightness). A hue difference is not allowed, a lightness/saturation difference is. Removing that technique would remove that clarification(?). (In my view the technique is not backed up by the SC, but I have only so much time to argue that in my life.)

that needed to remain somewhere otherwise half the internet would retrospectively fail overnight

But earlier you said removing a sufficient technique doesn't make anyone fail anything because they are merely suggestions.

Do you understand my confuzlingshun now?

@StommePoes Because the WG wants to have its cake and eat it, too. They want Use of Color to only apply to hue, but won’t change the SC to reflect that. So they use this technique to argue that they meant hue instead of color all along.

This sounds like an important component to Rian's initial point then.

that needed to remain somewhere otherwise half the internet would retrospectively fail overnight

But earlier you said removing a sufficient technique doesn't make anyone fail anything because they are merely suggestions.

Do you understand my confuzlingshun now?

i'm not defending it. that technique broke the idea of normative vs. non-normative. it introduced a new normative definition in a non-normative technique, and then pretended that of course everybody knows "color" means "hue"...

now, it still defines this in a non-normative understanding document. not ideal. but slightly better than in a buried technique. and yes the point is/was that this should not have been done in the first place.

Because it was decided that the technique (G183) is used to clarify that color in 1.4.1 Use of Color means hue, not color (which traditionally consists of hue, saturation, and lightness).
To me the text of G183 is rather confusing. It says I might use a 3:1 difference in lightness, but should not because of users low vision. I assume that starting from a dark text on light background I end up with a text that is too light on the background to be legible anyway. So why bother?

And BTW, the link to "relative luminace" is a dead link.

Confession: I do NOT have read all techniques. I didn't know I had to do to create compliant sites.

I didn't know I had to do to create compliant sites.

Luckily, you don't... the idea was to give developers some ideas on what they could do (although as a tester I've used some of them to determine whether something a client has done is maybe enough to pass a particular SC). Some of them were good ideas. Some are outdated. But in theory you could ignore all of them and still be fine.

But in theory you could ignore all of them and still be fine.

i never looked at them, safe for a few cases where i was tipped off about them containing..."interesting" (read: controversial) reinterpretations.

the link to "relative luminace" is a dead link

nerdy side note: that's the wonder of the WCAG publishing system - if there's a definition link, but the definition link isn't also in the normative SC text itself, the understanding document will have a definition link, but no actual reference to link to at the bottom of the understanding document...

I believe the issue is, as the author suggests, with the W3C's outdated training material. However, I think the most important thing that we're dealing with is the fact that developers do not know, and do not want to know, HTML. Everyone is using frameworks, and these frameworks do not use semantic HTML. Suposedly, semantic HTML is outdated, or perhaps doesn't fit the way the frameworks want to apply CSS... Who knows exactly why -- I certainly do not. However, what I do know is that the web is moving away from semantic HTML quickly, and this is negatively impacting accessibility.

In fact, some people want to replace all HTML with direct-to-canvas rendering. Think of what this would do for accessibility.

The Future Web: Can Canvas Rendering Replace the DOM? | Young Coder | Matthew MacDonald
https://medium.com/young-coder/the-future-web-will-canvas-rendering-replace-the-dom-847be872884c

In this article, the author argues that this practice is gaining in popularity and holds Google docs out as a successfull (and accessible) demonstration of it's potential.

To be fair, he also argues that direct canvas rendering shouldn't be done when not necessary, but I dread the day when it is the default mode for most frameworks, and developers will code all sites as web apps because it speeds up rendering or because it makes prettier visuals.

I agree that the W3C's training material should be updated, but we really need to think about how to get the web back on track. Separation of semantics and presentation, and the concept of progressive enhancement have all but been forgotten. We need to teach these to developers, otherwise accessibility will suffer.

@RichCaloggero In this context, I think we have mostly been talking about reference material, i.e. the understanding and technique documents.

For training material, I'd point people to the WAI tutorials: https://www.w3.org/WAI/tutorials/

They may need updating as well, but they are still generally good for the points you raised about semantic HTML etc.

If you loop back up to the comments 23 days ago from Wilco and Yatil, you'll get more info on that aspect.

These cards are not a substitute for reading the full criteria, it's just a simpler way of trying to understand them:
https://guia-wcag.com/en/

Commenting to watch this thread :)

This may be of interest to folks here: PR 2012 aims to address at least some of the problems discussed in this issue.

Update for those following along (with a disclaimer that I left WAI end of October 2021 and did not manage to get approval to ship the redesign in my last week).

Sadly, the changes in PR 2012 were still not merged, it is now many months later and it is unclear when they will, if ever. Some of the main proposed usability improvements have been removed, too.

I realise this comment isn't super actionable, but wanted to add it to this thread for transparancy from my side.

Sadly, the changes in #2012 were still not merged, it is now many months later and it is unclear when they will, if ever. Some of the main proposed usability improvements have been removed, too.

It is almost as if this PR proves the premise of this thread, including changes made without any reference to any decision process after you stopped working on it. Very opaque from a process standpoint, which I would be OK if that would lead to quicker deployments of these important, dare I say essential, changes. But it seems to just linger around in WAI purgatory.

Spending time on "education" for an old standard which embodies an unfortunate number of inadequate, unsupportable, or even obsolete criteria is not a productive exercise IMO.

Further extensions to 2.x that are obstructed by mandated backwards compatibility despite proven deficiencies is also counter-productive to forward advancement.

Meanwhile, WCAG 3 as a complete replacement needs greater support and participation.

While there is no doubt that education and outreach is lacking and an important reason that accessibility is languishing, the foundational problem is the WCAG 2 "standards" themselves are confusing, difficult, and sometimes contradictory or even unsupported by primary research, or worse, of questionable utility.

Change is needed. But you don't build a house without setting a solid foundation first. WCAG 3 is an opportunity for a fresh start with a new foundation, and needs the focus and attention to develop into an effective standard.

@Myndex Well spoken.

But WCAG 3 will take years before it is finished and more years to be come a requirement by law. In the meantime countless developers have a hard time working to create WCAG 2 compliant websites for the reasons you have given.

If WCAG 2 is abandoned then it should be made clear on the website in big, bold letters that the creators acknowledge that coding for this standard is a lost cause.

As an update on this issue (and because I need to close anything marked "WCAG 2.2"), there is something happening which I think is a resolution to this issue. It isn't immediate, but it is what the group can do:

We are forming a group specifically to work on WCAG 2.x materials. It is currently small, meeting once a week to work on older materials. Once WCAG 2.2 goes to CR we will look at making that into a task force. I.e. it can make decisions and do updates without having to go through the whole group for everything. (Normative text changes would need to, but otherwise we can operate it on a transparency basis, keeping the group up to date on the changes).

On that basis I'll close this issue.