Visual Contrast and Readability methods and guidelines

[Myndex]

Introduction

Hello, I'd like to open a discussion regarding development of standards related to readability for internet content.

Executive Summary

WCAG 3 is years into the future, and will probably embody a few minimum standards for readability. But there is room for a greater depth of non-normative recommendations and best practices to improve readability. These can, and arguably should, be a separate independent set of guidelines, eventually a superset of guidelines beyond the normative minimums adopted by any given standard.

Visual Readability Contrast

Nearly three years ago, I began thread #695 on the WCAG Github, where I pointed out the several significant problems with the WCAG_2 contrast guidelines, including 1.4.3 adm 1.4.11, and especially the WCAG_2 maths and methods for estimating contrast. As that progressed, I took a proactive approach in solving these issues by leading the research and development of the solutions.

The International Reading Crisis

The internet destroyed the print industry. Major cities were once filled with newsstands. We had a massive newsstand here in Hollywood near my home that was a block long and densely packed with magazines and newspapers from around the world. But as the internet became popular, this newsstand shrunk over the years eventually closing completely some years ago. This is also true of the several area bookstores that have long since shut their doors.

Some estimates indicate that reading in general—internet and print— is down 40% over the last two decades. Certainly the growth of the internet is not the only factor, but there is a related concern: in the shift to mobile devices, it has become difficult it is to read for extended periods. Contrast is often too low, making fatigue high. There is a great deal of misinformation and misunderstanding regarding best practices for readability. And with the rapid advance of technology, WCAG_2 contrast guidelines became a part of this misunderstanding.

Let There (Not) be Light: Genesis of an Error

The WCAG_2 contrast guidelines were first developed circa 2005, before the birth of the iPhone and the subsequent mobile media revolution. In the early 2000s, web content was typically set with core web fonts, with black text on a light grey or white background, often HTML with no CSS, for viewing on (predominantly) CRT type displays.

Today of course the landscape is completely different. CRTs are museum pieces, and web content is viewed on mobile devices under much wider ambient conditions. The content itself is CSS-styled using readily available font services like Google Fonts which are available in any number of ultra-thin styles combined with unreadably low contrast colors.

To be sure, there were known problems with the WCAG_2 contrast guidelines at the time of adoption, but WCAG_2 was more focused on accessibility needs such as ARIA and related technologies. Modern technologies are not so forgiving. Designers are unhappy being forced to use contrast math results that are known to be wrong, while accessibility experts are in a difficult spot being forced to explain why these visibly wrong results have to be adhered to.

And the losers in this tug-of-war? All sighted users. The wrong math and inappropriate guidelines with the resultant misunderstandings surrounding color choices and contrast for readability has created a decidedly unreadable web experience.

The Perceptual Solution

As a result of some years of research (which is continuing) I authored the contrast section of Silver/WCAG_3 and also created the APCA (Advanced Perceptual Contrast Algorithm), APCA is a perceptually accurate method of predicting contrast for readability. APCA is demonstrating superior performance for readability compared to WCAG_2 contrast guidelines, here is a side by side comparison which illustrates the problem of false-passes that WCAG_2 1.4.3 can create:

A Constant Contrast Comparison

Each column set to a specific contrast. The top half of the table, each row has the same text color. For the bottom half, each row shares the same background color. Pink areas indicate out of range.

All sample fonts are at 400 weight. For APCA columns, sizes changed per APCA guidelines. To demonstrate extended range, cells that don't quite hit the target have the text enlarged per the APCA guideline, and have that cell's LC value listed in the pink area with an arrow.

While WCAG_2 degenerates to an unreadably-low-contrast as colors get darker, APCA maintains readability across the visible range, and you may notice a slight increase in APCA contrast for darker colors to address the cases of display flare and misadjusted black levels in monitors, and certain common mobile-use environments.

The Need for a New Standard

While the APCA was originally, and is still, aimed toward WCAG 3, that standard is still some years off from being the recommendation. Due to the charter for WCAG_2, changes must be backwards compatible (though there has been some discussion of relaxing that for a possible future version). It is difficult to make something that is perceptually correct like APCA, backwards compatible to an old method that is not perceptually accurate like WCAG_2. This is being partly addressed with "Bridge-PCA", and interim APCA-based method and guideline that is compatible with WCAG2.

While I have been working to create standards and guidance for WCAG_3, and in some cases WCAG_2.x, APCA is also being developed for other scopes and other guideline uses. The problem of readability is significant, and APCA and other related research needs to move forward to help designers, developers, accessibility advocates, etc. make better design choices that meet the needs of all sighted users.

In other words, as research progressed over the last three years, and in conversations with designers and developers, early adopters, and beta testers, it is abundantly clear that the scope is well beyond accessibility. 100% of sighted users have visual needs in terms of readability and distinguishability. And those needs are met with a comprehensive set of guidelines, beyond just contrast. For instance visual fatigue is as yet unaddressed, and a significant part of why reading for extended periods on devices is challenging for most people.

APCA is not just a new contrast math, it is a complete set of guidance for content presentation, weighted for readability, but based in modern vision science, empirical studies, consideration of current and emerging technologies, and most important the needs of users, and by users I includes designers and developers as well.

A Deeper Dive

Rather than list many links, here is a short list, on the linktree with key links to a deeper dive into the work that has been done thus far.

And for a more complete catalog of APCA related resources, please see:

https://git.myndex.com

Discussion and questions are welcome at the main SAPC-APCA repo in the Discussions tab: https://github.com/Myndex/SAPC-APCA/discussions

Beta Packages

APCA is presently public beta, and beta tools, and sample code is available at the GitHub repos and npm. The base version is:

 npm i apca-w3 

And the WCAG 2 compatible version, with alternate guidelines, is Bridge PCA:

npm i bridge-pca

Next, my question to you is how best to move forward here? And please let me know of any thoughts or questions, I am at your disposal.

Thank you,

Andy

Andrew Somers
W3 / AGWG Invited Expert

𝐓𝐇𝐄 𝐑𝐄𝐕𝐎𝐋𝐔𝐓𝐈𝐎𝐍 𝐖𝐈𝐋𝐋 𝐁𝐄 𝐑𝐄𝐀𝐃𝐀𝐁𝐋𝐄^™

[LJWatson]

Email notification sent to the Accessibility Guidelines WG in case there is interest in taking this up.

[WilcoFiers]

I feel that APCA's pending patent makes adopting it by the W3C problematic.

The one of a kind license under which APCA-W3 is distributed can also a be significant problem. Many organizations maintain a list of software licenses they're allowed to use the software from. Since it's not using a standard license, It prohibits the APCA-W3 package from being used in loads of organizations.

I totally respect Andy's desire to have (some) control over his work. And I wouldn't want to see that changed if that's how Andy want this. But it creates roadblocks that I don't think can exist if this is to be the world's next set of color contrast guidelines.

[Myndex]

Hi @WilcoFiers

You must not be aware of the backstory here, except I know I've discussed this with you in the past. The only reason for the patent filings is due to the plagiarism, harassment, and discrimination I have personally encountered as a result of my involvement with the W3C/AGWG/LVTF. The license is temporary, so that I have legal recourse relating to certain bad actors that are bent on obstructing actual accessibility.

APCA and the APC-Readability Criterion are being developed as a free-to-use standard, now being administered by Inclusive Reading Technologies, Inc, a California non profit.

Free-to-use means it is not at all problematic for W3C.

License Roadblocks

As for roadblocks, that was at the request of chairs of the AGWG, who wanted me to curtail the sudden popularity of APCA, which readily found acceptance (because it actually works). The way to do that was to make the license less permissive temporarily to slow what was/is a very rapid adoption.

But it was also necessary due to certain bad actors creating poorly functioning, unauthorized derivatives, then calling them APCA, to provide a means for others in the obstructionist group to denigrate and obstruct the work we have been doing.

I have been providing permissive licenses per request. But the eventual permissive license will be set after and in conjunction with incorporation into standards. This will be APC-RC first, as it is already being successfully used, and is demonstrably superior to WCAG2 contrast SCs.

Liabilities

There is a tertiary issue, unrelated to anything the W3C has any purview over, and that is use of the technology in certain other spaces (medical, aerospace, military), that present legal liabilities we need to sort out.

But right now I am more focused on research and exploring additional features, and trying not to worry about the legal aspects. And again, if it weren't for certain bad actors, these issues never would have come up.

We've had breakthrough discoveries via the studies we've been doing in the lab here, but I stopped being open when I've had certain individuals telling me straight to my face they won't sign an NDA and anything I reveal to them they intend to plagiarize.

What would you do with in-development work, in this kind of abrasive environment Wilco?

???

I'd like to point out that the W3C has a patent policy in place, and plenty of patents that are licensed to W3C on a free-to-use basis. I know you know this Wilco since I've pointed these issues out to you before.

So I have to ask, what is your motivation here in bringing this up in this way and with this tone?

[LJWatson]

@Myndex can I remind you that W3C operates under a Code of Conduct that cautions against using "Language or behavior that may appear kind or helpful but conveys a feeling of superiority or condescension". Thank you.

[nayanecom]

We would like to see this proposal from Myindex advanced.

[LJWatson]

@nayanecom I've hidden your previous comment because it duplicated the entireity of @Myndex's original proposal, and your comment after that appears to duplicate https://github.com/WICG/proposals/issues/55#issuecomment-2137457000.

[nayanecom]

@nayanecom I've hidden your previous comment because it duplicated the entireity of @Myndex's original proposal, and your comment after that appears to duplicate #55 (comment).

i deleted it as it was an error. thanks

[dbjorge]

I would love to be able to consider APCA as a contrast method; I definitely agree that WCAG 2's contrast algorithm has many weaknesses and APCA has many technical merits.

Unfortunately, I must add a big +1 to Wilco's concerns about the licensing (disclosure: Wilco and I work for the same company).

I want to stress that this is not a specific attack on APCA (and certainly not on Andrew personally). I would object to spending working group time exploring a requirement based on any patent/trademark-encumbered algorithm (APCA or otherwise) unless/until we had the following minimum requirements in place:

1. The patent disclosure and binding RF licensing commitment described by the W3C patent policy
   1. ...to be in place (or at least in progress) before we start expending any significant work on writing guidelines based on the algorithm, which is a bit earlier than the policy demands
   2. Including the exact text of the committed license terms
   3. ...which must be practically compatible with including an implementation (not necessarily the reference implementation) in accessibility testing tools. For example:
      • Must be able to implement within a proprietary product (without the "make available for review" condition)
      • Must be compatible with publishing an implementation as part of open source products that use standard OSI open-source licenses
      • Must not obligate it to be free of bugs
      • Must not obligate the use of specific versions of dependencies
      • Must not limit the environments/use cases it may be used in (eg, "web content only")
2. Agreement that the Specification will not (primarily) refer to the algorithm by any name which is trademarked (ie, users need to be able to refer to a specific Outcome/Requirement/whatever without worrying about trademark issues)
3. If there is an official reference implementation...
   1. (not a hard requirement) Ideally, it'd be licensed under a standard permissive OSI license (BSD/MIT/Apache/etc)
   2. ...but if not, its license should be clear that it applies only to the reference implementation and use of trademarks, not trying to apply to other implementations just because they use information the Specification will need to incorporate (eg, constant values)

With APCA specifically, I am concerned mostly because the current version of the LICENSE in the apca-w3 repo is incompatible with points 1.3 and 3.2 above (particularly L10, L12, L14, L36, L49-54, L57, L60, L64, L68, L69, L72, L87-89, L94-111, L115-131). I understand that the stated intention is "the eventual permissive license will be set after and in conjunction with incorporation into standards", but I'm afraid I don't think that's satisfactory; I think we need a binding guarantee that the licensing will be sufficiently permissive before (not after) we spend time writing a standard based on it.

[marcoscaceres]

Hi All, we are reaching out to W3C to help get us some legal advice on this matter. If it's ok, can we wait a few days until we hear back from legal counsel?

I'm going to temporarily prevent commenting here until we hear back from the lawyers.