Early December of 2021, Eric Eggert (Yatil) continued his derisive commentary regarding new contrast methods proposed in WCAG 3. His opinion piece has been re-used and re-posted over the last few years by others of a small group of individuals that have been actively obstructing the improvement of readability and visual accessibility standards. We refer to them collectively as "the obstructionists".
The piece itself is of little value, but it has come to our attention that it is being used as a reference, cited to obstruct the progress of actual accessibility research by creating an atmosphere of confusion and animosity. As such, it needs to be challenged. It does not contain facts, but rather is a string of provocative logical fallacies, as discussed below, on a line by line basis.
We've hesitated giving any consideration to the postings of what amount to "trolls", as usually the best course of action is to ignore—and certainly, we are not promoting this page. In general, our focus is on improving actual accessibility. We know the truth will prevail, and this has been the case for the most part. But we have been made aware of implications and actual harm that is being caused within the accessibility community by these ludicrous assertions. Therefore we need at least to have a document to point to as a response.
This document is intended to provide clarity, for those that find Mr. Eggert's unsupported opinion confusing on these issues.
Yatil:
No one said it was, but parts are/were certainly ready for testing, and actively undergoing tests. APCA was brought to the public view and published as an npm package December 2021 to enable the larger public beta period for testing and evaluation. Mr. Eggert's opinion piece, along with actions by other obstructionists, had a chilling effect, including the disruption of the beta program, and causing some beta testers and early adopters to drop out of the beta test program.
Yatil:
And it won’t be for quite some time.
Logical fallacies: reciting facts not in evidence, false premise, appeal to ignorance, and uninformed rhetoric.
At the time this was stated, WCAG 3 was expected to evolve within a few years. However, as a result of the obstructionists, WCAG 3 was brought down and restarted nearly from scratch, and as a result, now does not have any clear release date.
Because of the importance of visual accessibility, the APCA and APC-Readability Criterion is now on a fast-track development with the non-profit Inclusive Reading Technologies, Inc.
Yatil:
In the last couple of weeks, more and more people point at the WCAG 3.0 Working Draft and recommend the adoption of aspects from it that suit their needs, despite the draft clearly stating (emphasis theirs):
The "aspects of it" is the contrast method, APCA. People are using it because the existing WCAG 2 simply does not work. Those that had been adopting it in 2021 were part of the wide public beta program, devised to ensure that future contrast methods did not fail, the way WCAG 2 contrast has.
Yatil:
These are early drafts of guidelines included to serve as initial examples. They are used to illustrate what WCAG 3.0 could look like and to test the process of writing content. These guideline drafts should not be considered as final content of WCAG 3.0. They are included to show how the structure would work.
Logical fallacies: begging the question (circular argument), false dilemma, equivocation (doublespeak), post hoc ergo propter hoc (after this, therefore because of this, i.e. false correlation), straw man argument (unrelated/irrelevant argument).
They are included as guidelines to test and evaluate the process of creating the guideline, process of using, and of testing the guideline function as part of the public beta test, etc.
In 2021, as well as now, WCAG 2 is not "mandated law" in most of the world, though unfortunately it has been added to some rules in some specific cases, despite the known failings and potential for harm. More on this a bit later.
Yatil:
W3C Working Groups publish drafts to allow the public and W3C members to give feedback. They are explicitly not meant as a recommendation or even as advice. To quote from the W3C process document (emphasis mine):
Logical fallacies: begging the question, false dilemma, appeal to ignorance, reciting facts not in evidence.
How is the public to give feedback, if they don't actually try and use something? What benefit would that provide? None. All guidelines need testing and evaluation. APCA was and is undergoing evaluation, in real world circumstances, using real websites and tools developed by and for designers.
No one ever claimed WCAG 3 was a "recommendation", however when it comes to contrast, WCAG 2.x contrast SCs are so poorly conceived and unusable, that many were eager to try out the new and functional APCA method.
And in fact, by December of 2021, the APCA method then (and now) in testing was not the version first shown in the January 2021 WCAG 3 working draft, and had already advanced substantially beyond that. The stable beta version was released February 15th 2021 (version 0.98G-4g). Taking a conservative approach, nearly a year later the 0.98G-4g beta was made available as an npm package, to help assure consistency across early adopters and beta testers.
W3C Process as quoted by Yatil:
Working Drafts do not necessarily represent a consensus of the Working Group with respect to their content, and do not imply any endorsement by W3C or its members beyond agreement to work on a general area of technology. […] A Working Draft is suitable for gathering wide review prior to advancing to the next stage of maturity.
Which refutes the statements Mr Eggert made previously, elsewhere he has claimed that "there is no provision for testing in WCAG" and other nonsense. The working draft is explicitly for testing and wide review. So which is it Mr. Eggert? That there is no provision for testing as you stated elsewhere? Or that there is testing?
Yatil:
In general, web technologies are very good citizens to early adopters like me: They usually come with suitable fallbacks that allow you to use, for example, animations and transitions in 2009 with the fallback of no animation for browsers without support.
Logical fallacies: reciting facts not in evidence, setup for an appeal to ignorance.
In other words, this comment is not at all relevant. APCA exceeds the meager requirements of WCAG 2, and no "fall back" is specifically needed.
Nevertheless, we also released Bridge PCA which is a simplified version that is a drop in replacement for the unreliable WCAG 2 math. Moreover, WebAim's studies show that 86% of websites fail to use WCAG 2 contrast (in large part as it does not work), so here Mr. Eggert seems to want to fall back to a spec that is known to be a fail.
Yatil:
With guidelines like WCAG 2.1 and 2.2 (to be released later), the same approach is true. If you use WCAG 2.2 Success Criteria now, the Guidelines are built to be backwards compatible. So you will never break a 2.0 or 2.1 audit by using it.But WCAG 3 breaks backwards compatibility. This is a conscious move to better adapt the standard to serve different disabilities which WCAG 2 did not sufficiently cover, due to its structure.
That means that WCAG 3 will probably have a different scoring system that does not necessarily overlap with WCAG 2. As far as I know – and my involvement was some time ago – the current plan is to make sure all WCAG 2 conforming pages conform to WCAG 3, too, in some form. They will not in reverse.
Logical fallacies: reciting facts not in evidence, fallacy of equivocation, false analogy, arguments from analogy, straw man.
These paragraphs are confusing to say the least. And further, forward/reverse conformance had (at that point) not been a key consideration. The consideration at the time was to start with a clean slate with WCAG 3, in order to allow a departure from the areas where WCAG 2.x makes unsupportable demands.
Let's discuss this, as the "backwards compatibility" issue is the core of Mr. Eggert's demurrer.
Just to clarify, the backwards compatibility being referenced here, as stipulated under WCAG 2.0, means that if something "fails" under WCAG 2.0, that it therefore "must" fail under all future versions. But, any future version of WCAG 2.x may add features that might not fail under a previous version.
In other words, the guarantee posited by AGWG and WCAG 2 is that if you pass a future version, you automatically pass all of a previous version.
Thus, the backwards compatibility here as mandated in WCAG 2.x is the ultimate hubris, as if to claim that technology does not change and that AGWG and WCAG 2 have infinite knowledge of the future.
Such a premise is absurd on the face of it. Moreover, even the AGWG has disregarded the backwards mandate by removing an SC from WCAG 2.2
In the case of contrast under WCAG 2, it can actually make things worse for people with color vision deficiencies. Further, WCAG 2 contrast has no peer-review nor empirical studies, and has been widely criticized. In other words, it is wrong, and it is wrong for it to be in any standard.
The claim that it "can't be changed" due to backwards compatibility issues is an untenable, unpersuasive argument.
Yatil:
The visual contrast algorithm that is currently referenced in the WCAG 3 Working Draft, named APCA, is a stark departure from the luminosity contrast algorithm used in WCAG 2.
Logical fallacies: hyperbole ("stark departure"), use of unsupported negative phraseology.
Yes, APCA is a bit of a paradigm shift, as is needed to replace the flawed and much maligned WCAG2 contrast methods and guideines. And how "stark" the departure depends on the level of improved accessibility one desires. And this has little to do with APCA the algorithm, and more to do with the more flexible guidelines that a perceptually uniform algorithm permits.
For instance, the "Bronze Simple Mode", created in response to statements like this, is a basic and simple guidelines with basic threshold levels—but using correct math and methods.
But "Stark Departure" is hyperbole. Both the basic APCA and the WCAG2 test a pair of colors, and provide a value. The difference is that the value provided by WCAG2 is not meaningful, and not at all consistent over the visual range, and this requires brute forcing of threshold levels. APCA is consistent, i.e. perceptually uniform, and that allows for a more complete and useable set of guidelines.
Yatil:
WCAG 2 treats front and background color the same, so inverting the color does not change the calculation. This is notably not how color perception works in practice. You can perceive certain colors better or worse, depending on the surrounding color.
WCAG 2 does not take font-size and weight into account, the APCA does.
WCAG 2 did not change the required contrast depending on the font, APCA does.
Logical fallacies: FALSE, false equivocation, misdirection, and omission of facts surrounding WCAG 2 to claim it is simpler.
WCAG 2 does have font-size and weight breakpoints for normal and bold fonts. Arguably, this is wholly inadequate. But it is also disingenuous to imply that WCAG 2 is better or easier to use because it is claimed to be "simpler", and omitting the fact that WCAG 2 has rudimentary font requirements is the basis for Mr. Eggert's argument that APCA is "more complicated". If one has to lie to make a point, then they have no point to make. In this case, it is an easily verifiable lie, as all one has to do is read the WCAG 2.x 1.4.3 SC.
But more to the point, saying "WCAG 2 is simpler" falls flat—designers and content developers certainly don't think so, nor do those with color vision issues who are not well served by WCAG 2.
The WCAG 2 breakpoints have no support in peer reviewed empirical studies, and no effort is made to recognize that "font-size" does not relate to the actual text size as rendered on screen. Further the contrast levels of 4.5:1 and 3:1 can be either completely inadequate, or paradoxically, more than is needed. Thus, being "simple" is useless if it also means being wrong. WCAG 2 barely considers spatial aspects, but moreover, the asserted "simplicity" is not a virtue, it is a part of how WCAG 2 contrast SCs fail as guidelines.
There is nothing about the APCA algorithm that prevents this simpleton approach. In fact, BridgePCA is a simple drop-in replacement for WCAG 2's faulty math and methods. But with the full APC-RC guideline comes both improved accessibility, and improved flexibility. The APC-RC is designed with good design in mind from the get-go.
Facts: contrast perception of most text (as well as lines thinner than about 4px) is primarily driven by these spatial characteristics. The font weight, size, or line thickness is the primary driver, as that is directly related to human contrast sensitivity. This is a matter of well developed, peer-reviewed scientific consensus, going back half a century at least (See Stevens et alia). APCA considers these well established aspects of visual perception, and the APC-RC guidelines are all referencing the well established scientific consensus in readability (Legge, Whittacker, Lovie-Kitchin, et alia).
APCA and the APC-RC are a product of years of research and investigation, using well established peer-reviewed science, and with years now of open public testing.
WCAG 2 referred to none of that, instead cherry-picking from an obsolete 1988 standard for monochrome CRTs. So we find it curious that Mr. Eggert and friends are demanding that people adhere to the old, and deeply flawed SCs such as 1.4.3, which does not support actual accessibility, and in fact can be harmful to readability.
Yatil:
- These are all good arguments to change to a new way of measuring contrast, especially as APCA also promises to give designers more color choice. However:
Any color combination with APCA needs to be checked for both font-size and weight, making requirements documents and design systems more complicated.
Logical fallacies: false equivocation, begging the question, false dilemma, appeal to ignorance, reciting facts not in evidence.
As stated, and as listed in the WCAG 2 document, font size and weight also must be checked. Thus, the claim that APCA is "more complicated" is unpersuasive.
The APC algorithm, being based on human perception, provides a substantially more accurate prediction of perceived contrast (as mush as a 250% improvement over WCAG 2). Having an accurate model allows for useful guidelines, such as the APC Readability Criterion, which provides designers with useful and actionable guidelines for font size and weight. And designers have been very supportive of the sliding scale that permits greater design flexibility using the APC-RC.
In response to Mr. Eggert's negative views, we developed the "Bronze Simple Mode" guideline, which uses the APCA algorithm, but breaks the guidelines down into a few simple breakpoints, not unlike the 1.4.3 SC. We also developed the BridgePCA, which is a literal drop-in replacement for the flawed WCAG 2 contrast math, and is backwards compatible therein.
We developed BridgePCA in part to get a better understanding of the underlying motivations of the obstructionists. BridgePCA is backwards compatible to WCAG 2 contrast, and substantially improves actual accessibility. Yet the obstructionists have completely ignored it. This clearly demonstrates the obstructionists have goals unrelated to improving accessibility. Their negative viewpoints should be weighted with this in mind.
AS A SIDE NOTE: To be clear, there is nothing at all about the APCA algorithm that prevents "backwards compatibility" to the old WCAG 2. APCA itself is just an algorithm that predicts contrast perception. It is a matter of the development nd writing of the guidelines that answers the question of backwards compatibility.
The area where APC-RC guidelines are intentionally not backwards compatible with WCAG 2, is the area where WCAG 2 is harmful to readability for color insensitive folks. This is the one area where Mr. Eggert and friends are frequently claiming that "you have to follow WCAG 2 because, laws..." which is not supportable, when the failings and bad law that WCAG 2 creates have not been proven in a court of law as valid.
That said, to answer the demurrers Of Mr. Eggert and others in the obstructionist group, we developed Bridge PCA, which uses APCA technology, but is adjusted for backwards compatibility with WCAG 2. That the obstructionist group refuses to acknowledge this is further proof that their underlying motivations are not aligned with actual accessibility.
Yatil:
Designers compare the used font to the standard, Helvetica-based, APCA lookup table. This feels like an error-prone step to me, considering that this comparison seems to be done on a visual level. It is not only excluding people with visual disabilities from making their own (accessible) font and color choices, but it also brings a certain level of subjectivity into the rating.
Logical fallacies: hasty generalization, false equivocation, red herring, straw man, genetic fallacy, and ableism.
This statement is incomplete, and not accurate. There is a list of pre-qualified fonts that fit the paradigm of actual accessibility.
And there is a well defined procedure for qualifying alternate fonts, and is a task that only need be done once. The level of subjectivity is minimal, being binary in nature, i.e. a font is either heavier or lighter than the reference at a given weight, and determining this value as ±100 in weight is sufficient.
But more importantly, the line claiming "...excluding people with visual disabilities..." is as provocative as it is dishonest, with no basis in fact.
Yatil:
How the APCA values convert to WCAG 3 ratings is not 100% clear to me.
And yet Mr. Eggert refused multiple good faith attempts to discuss the basis of the ratings, and merits of providing different levels of conformance. If it is not clear to him, he is being actively obtuse and passively ignorant of the documentation.
We have offered to provide zoom call discussions to answer questions and show the research and basis for the work being done—or to join in the forums with discussions. But they (the obstructionists) have ignored these good faith attempts, and instead gaslight the community. This speaks volumes toward their motivation.
Yatil:
The rating section in the draft (expand the “Rating for Luminance contrast between background and text” for more info) refers to the lookup table values and how you can not meet a number of them and still get a rating. (WCAG 3 aims to not have clear pass/fail criteria, but looser ratings, that give websites the opportunity to be a bit inaccessible and still conform to WCAG to a certain extent.)
Logical fallacies: appeal to ignorance, reciting facts not in evidence, hasty generalization, false equivocation, red herring, straw man, direct falsehoods.
Among the problems with WCAG 2 is the lack of any guidance regarding minimum font sizes. Under WCAG 2 you could have main content text at a size of 6px and still pass, despite being unreadable to most users. Yet he claims that WCAG 3 had "looser ratings", after earlier claiming that WCAG 3 was "more complicated" and implying harder to pass. Well, which is it?
This leads into Yatil's assertion that "...be a bit inaccessible and still conform to WCAG..." which is patently false. It is a provocative statement he's been repeating, but it is very simply a lie. And again, conforming to WCAG 2 by the numbers has been shown to create actually inaccessible results. WCAG 2 contrast is weak, and does not support, much less mandate, actual accessibility. 47% of the color pairs that WCAG 2 passes should fail under a properly developed system. A designer could follow WCAG 2 and make a site pass by the numbers, yet be actually and factually inaccessible.
APC-RC provides for fewer color pairs in total than WCAG 2, but all the color pairs under APC-RC are useable, while this is definitely not the case with WCAG 2. Further, 22% or more of the color pairs WCAG 2 rejects are perfectly useable with the correct font weight, and provide for a better experience for color insensitive users.
Yatil:
The – admittedly also draft – design and development information for ”Visual contrast of text” has little actually actionable information at this point: How do I choose colors? How do I make sure my design system complies? How do I measure the colors practically? It has some information on display color calibration and the environment, but in my opinion, those should be relevant for determining the contrast using the algorithm.
Logical fallacies: appeal to ignorance, reciting facts not in evidence, Circular Argument, false equivocation, Red Herring, Straw Man.
Mr. Eggert is directly relating to a very early draft guideline, yet at the time he wrote this opinion piece, the more complete guidelines had been in public beta for nearly a year. We made good-faith efforts to show Mr. Eggert the works in progress, yet Mr. Eggert refused any attempt to discuss the actual facts and guidelines, instead writing opinion pieces such as this that fully disregard the actual working guidelines, and the current version that was published to npm, and that is tested.
Yatil:
The APCA algorithm is changed occasionally (last in March 2021). It’s good that it adapts to new research, but it also means that you might use a color that is not sufficient by a later version.
Logical fallacies: appeal to ignorance, reciting facts not in evidence, false equivocation, Red Herring, Straw Man.
The APCA algorithm was last modified February 15th, 2021. This is the version that has been in public beta, and successfully used for three years at this point. There are a few features we are going to add in 2024/2025. Otherwise, the APC algorithm is stable and very useable, as it is based on, and references decades of established, peer reviewed vision science.
Yatil:
This reads much more complicated to me, compared to the current way of using colors. It is probably more exact, but it trades off clarity. Designers might get to use orange and white, but there is an additional effort on how complicated it is to evaluate and describe accessible designs.
Logical fallacies: appeal to ignorance, reciting facts not in evidence, false equivocation, Red Herring, Straw Man.
What does this paragraph even mean? How does APCA "trade off clarity" while being "more exact". This is another baseless logical fallacy intended to confuse not illuminate.
Designers can use some values of orange and white because this supports actual accessibility, especially for those with color vision deficiency. WCAG 2 does not support actual accessibility, and some of these color pairs it rejects does so at the expense of accessible design.
Yatil:
That trade-off might be totally worth it, but there are many questions that need to be answered between now and then.
Logical fallacies: false dilemma, appeal to ignorance, reciting facts not in evidence.
What questions? And what does Mr. Eggert think was the reason we have an extended public beta period?
Here's the actual trade-off: WCAG 2 does not work, is harmful to readability, and designers do not use it. APC-RC works and provides substantial improvement to readability, using guidelines that have been tested and that provide useful guidance to designers, in the pursuit of actual accessibility and visual readability.
Yatil:
So, should you use APCA?
The answer is two-fold:For private, non-commercial projects: Sure, go ahead and apply it to the best of your knowledge. There are no restrictions on what you can do, and it might even inform future developments in WCAG. For commercial and public projects: You are probably, through law or policy, required to conform to WCAG 2. That means you cannot rely on APCA for compliance (simply because it does not exist in WCAG 2).
Logical fallacies: appeal to fear, post hoc ergo propter hoc, appeal to ignorance, reciting facts not in evidence, false equivocation.
Among the canards asserted by Mr. Eggert and others of the obstructionist camp, are those relating to law. WCAG 2 is a voluntary guideline and not law. In 2021 when written, WCAG 2 was not law in an absolute sense, there were some rare examples where legislatures copied from the WCAG 2 SCs. Even today, many cite the EU's EN 301, but this does not come into actual force until 2025, and then, not even full force until 2030.
In the USA, the US Access Board's 508 rules adopted the SCs from WCAG 2.0 (but not later versions), but the 508 rules include clear exceptions, importantly, the "equivalent facilitation" rule, which clearly permits the use of improved guidelines such as the APC-RC.
Yatil:
WCAG 3 and the consensus process will probably mean that it takes another 3–5 years until WCAG 3 sees any release. And then WCAG 2 will be still enshrined into a lot of laws and policies. After all, WCAG 3 is a huge monolith of a specification, and the structure that the Working Group wants to use is very complex. You can read about it in the WCAG 3 explainer.
Logical fallacies: False Dichotomy, Equivocation, Hasty Generalization, post hoc ergo propter hoc, reciting facts not in evidence.
This comment was part of the force that was used to halt development of WCAG 3 and start again from scratch. Today, WCAG 3 is an unknown distance in the future.
As a result of the problems that have arisen with WCAG 3, the APCA is now being developed independently with the non-profit Inclusive Reading Technologies, Inc., to ensure that useable guidelines supporting actual accessibility are available to the public on a free-to-use basis.
Yatil:
In the meantime, WCAG 2 is there for you. Is it perfect? No. Is the luminosity contrast flawed? Pretty sure. But that should encourage us to take the time to make sure that we don’t make similar choices in WCAG 3. As I have outlined previously on this very blog, I don’t think WCAG 3 is necessary the silver bullet that we think it is.
Logical fallacies: False Dichotomy , Equivocation, Hasty Generalization, post hoc ergo propter hoc, reciting facts not in evidence.
We brought the problems of WCAG 2 to the forefront in April of 2019 in GitHub WCAG issue thread #695. And we have been open about our research and development since that time. There is a discussion forum dedicated to contrast, color, and readability at the main APCA repository.
Yatil:
What is the way forward?I think exploring APCA and how it works with your particular color needs is a good first step, and the Accessibility Guidelines Working Group probably welcomes that feedback. If you use it, be aware that you might not conform to WCAG 2, and you cannot conform to WCAG 3 (as that does not exist yet).
Logical fallacies: False Dichotomy, Hasty Generalization.
We are not presently concerned with WCAG 3, but we are concerned with those that have been bullied into using WCAG 2, despite the well known problems. This kind of gaslighting should not be accepted. The general tone has permeated this subject, with spurious assertions of "WCAG 2 is bad but it's the only thing you can use" which is bizarre and not at all in touch with reality. Annual surveys have shown that some 86% of websites fail WCAG 2 contrast SCs.
The cause of these failures is multi-fold, but one key reasons is simply that WCAG 2 contrast SCs are not fit for purpose, and can be harmful to accessibility especially for color vision deficiencies. It should be no surprise, and in fact very telling, that so many of the early adopters of APCA are in fact color insensitive (aka color blind). The lead researcher and inventor of APCA, the author of this rebuttal, became focused on this project due to his own visual impairments.
To wit: The APC-RC guidelines are derived from peer-reviewed readability research. WCAG_2 contrast is based on an obsolete 1988 standard for monochrome "matrix" CRT displays.
Yatil:
I’m very worried that some designers might think they should or can use the new contrast algorithm, and then accessibility consultants have to push back and clear up those misunderstandings. It takes up a lot of time, while accessibility consultants have their hands full already.
Logical fallacies: equivocation (doublespeak), appeal to authority, false dichotomy (false dilemma), straw man argument, red herring.
In this statement, Mr. Eggert's faux concern that accessibility consultants "have to push back" on sanctioned and supported efforts to improve accessibility using a modern science-based guideline is absurd on the face of it. There is in fact something else going on here, and it has nothing to do with contrast, and much to do with cluster B personalities.
At the time, APCA was offered only as a clearly stated beta test, and then only because it had become clear in laboratory testing that the system was a major improvement, which was the very reason for the public beta. and instead promote a guideline that does not support actual accessibility and is unusable to the point that 86% of website do not use it. This is a "cut off your nose to spite your face" form of cognitive dissonance.
A proactive effort would be to encourage the EU to provide useful exceptions in EN 301 to allow for modern methods, instead of demanding deeply flawed guidelines be followed such as WCAG_2 contrast SCs 1.4.3 and 1.4.11. In the initial due diligence in 2019, the author of this rebuttal was shocked to find that the decades of advanced readability research conducted in the late 1980s and 1990s was ignored in 2007 when WCAG_2 was created. The WCAG2 contrast SC was loosely based on an obsolete 1988 standard for monochrome CRTs, with a function added to estimate luminance from RGB. But was objected to back in 2007 by major stakeholders like IBM.
Yatil:
Additionally, it gives accessibility a bad reputation: “You can’t even agree on what colors we should use. Accessibility makes everything more complicated!”. This already is a common sentiment, and speculating what the future might be, based on an early working draft, will not help with it.
Logical fallacies: straw man argument, begging the question (circular argument), post hoc "post hoc ergo propter hoc", red herring.
This claim is a fostering of cognitive dissonance at the expense of actual accessibility.
The fact that WCAG 2 promoted a contrast metric that was not peer-reviewed, not tested, and was even objected to back in 2007, is the actual source of any "bad reputation". The fact that we in the Visual Contrast group spent years developing a stable and useable guideline is not at all contributing to the alleged bad reputation. On its face, Mr. Eggert's claim here is purely for the purpose of disparagement.
Following WCAG 2 SCs can make a site inaccessible. Consider GitHub's dark modes—all of them are essentially useless except for the "dark hi con" version which is too high of a contrast. This author has a hard time with the visually inaccessible GitHub issues. The fostering of this "WCAG 2 is all we have so use it or else" attitude has harmed the development and advancement of visual accessibility on the web. And it's time to put a stop to this nonsense. Call it cognitive dissonance, call it gaslighting, or just call it a pile of dung—the attitude expressed is harmful, unsupportable, and the true motivation has nothing at all to do with supporting accessibility.
Yatil:
What if…?In an alternate universe, we would have a modular WCAG (similar to what CSS is doing) where every two years or so we package up new success criteria into a new version. It would have allowed different speeds for different SCs, and in this case, we might have a better understanding on what the way forward would be. And if our rating or evaluation guideline would change, the next version of that Success Criterion could address it.
Logical fallacies: post hoc ergo propter hoc, appeal to ignorance.
And yet, when that was proposed for WCAG 3, it was shot down. This could have been a valid concept, yet some obstructionists put a stop to it. It would have worked well with APCA as it was maturing rapidly though the beta period, and that would have brought more attention to WCAG 3, helping it gain further support.
Yatil:
That said, it is so easy to think in these inconsequential hypotheticals. The W3C consensus is that WCAG 2.2 is published some time next year. WCAG 3 follows when it’s done. It’s a long process, and we need to make sure all our i’s are dotted and the t’s are crossed. Let’s just make sure we don’t get ahead of ourselves and create confusion.
Logical fallacies: bandwagon logical fallacy, slippery slope logical fallacy.
How about focusing instead on creating sites that are actually accessible? How about that for a change? This "WCAG apologist" stance is untenable, if not actually harmful.
Yatil:
Maybe the article did not make that clear: If you use a color that has enough contrast to the algorithm specified in WCAG 2 and the one that is maybe coming in the future, that is great, and it will give your color combination a certain longevity. Combining both means cutting off obviously hard to read color combinations that are allowed under WCAG 2 while not venturing out of the color space WCAG 2 has inhabited. That means you raise your level of accessibility beyond the minimal requirements of WCAG 2. And that is awesome.
Okay, but the reality is that WCAG 2 interferes with accessibility and creates confusion by rejecting useable colors that are preferred for accessibility reasons.
Moreover, the deep misunderstandings and invalid claims exhibited on the Understanding document will take years to correct, and in the mean time has created significant animosity with this "us vs them" attitude that permeates into the accessibility community from the obstructionist group. Sorry but no. User needs are as diverse and the human spectrum of 7.9 billion people. Promoting bad guidelines—that are known to be bad—is an untenable position.
Again, WCAG 2 was a product of organizational politics, and not of science or a practical understanding of visual needs. There was a vision scientist involved early on, who as legend has it threw up his hands in frustration. He was not involved with 1.4.3, which has no valid evidentiary support for its method nor the claims made. That scientist later wrote an article in 2017 significantly criticizing the poor state of contrast standards around the world, citing their lack of empirical basis. In fact it was that very paper that inspired the author of this rebuttal to press onwards in research and development despite the obvious political challenges, because this was a problem that needed a stable and well developed solution.
Yatil:
WCAG 3 is still not ready. In fact, there haven’t been any meaningful updates to the draft since this article was initially published. The proposed charter for the WCAG WG has a completion date of Q2/2026, which is probably unrealistic. (Minor WCAG 2 updates took between 5 and 10 years, but now they want to create an entirely new standard with new testing requirements and documentation in three years?)
Logical fallacies: hasty generalization, post hoc ergo propter hoc, reciting facts not in evidence.
First, there are a couple obstructionists involved with AGWG who blocked the updates to the WCAG 3 draft amid an environment of ableism and discrimination. The updates were presented as a pull request in June of 2022 and was peer reviewed and approved by W3C technical director and approved by a W3C member with the US Access Board, and peer reviewed by a PhD from Cambridge. But this is where instead of a "modular" method, WCAG 3 was brought back to square one, to try yet another structure.
That update instead became the public working draft hosted at APC-Readability Criterion. The essential beta version has now been in use for over three years. It is not "entirely new" though it is a slightly different paradigm. And the Bronze Simple mode and BridgePCA modes were designed to be remarkably similar to WCAG2 in practice, to ease the transition, but are substantially more supportive of actual accessibility.
For more background on APCA and Readability, you may find these links helpful:
- Easy Intro to APCA a brief, easy to read intro to user needs for readability of digital content.
- Myndex Linktree a short curated list of key resources, tools, and documentation.
- The APCA Discussion Forum the discussion forum on GitHub, free to join in the conversation.
- APC-Readability Criteria Public Working Draft of the next generation guidelines for visual accessibility and readability.
See: SIDEBAR: Organizational Politics
Legislatures should be aware that WCAG 2 is not fit for use in law or regulation; if it were a voluntary guideline, the potential for harm would not be such a concern, but when elevated to statute law, the potential for harm is unacceptable. The unfortunate part here is that the serious problems of WCAG 2's contrast SCs cast a dark shadow on the rest of WCAG 2. Moreover, the nature of the problems with 1.4.3 and 1.4.11, if elevated to law, result in the blocking of improved and more accessible visual content guidelines.
WCAG 2's contrast math/methods do not support actual accessibility, and in fact can result in conditions that are worse for those with color vision deficiencies. The understanding docs of WCAG 2.x contain false or misleading information, and the premise lacks scientific support. 1.4.3 and 1.4.11 should not be incorporated into any laws nor regulations.
Thank you for reading.