A11y text color contrast fix

[sbddesign]

This PR potentially closes #831. I reworked colors across the site to improve contrast for our a11y push. I just wanted to try this so we could see what it would look like and evaluate the right approach.

• I sought to meet WCAG AA. As I understand it, most websites should strive for this. WCAG AAA has very strict requirements, which would be good to meet if you are building a product meant to be used specifically for visual handicaps. But for our purposes, I think WCAG AA is sufficient. Correct me if I'm wrong on that.
• Body text - I made this #000000 throughout. I don't think the subtle gray is that noticeable to most folks, and it doesn't help the links contrast at all by having the text non-black.
• Normal sized links (less than 24px) - these are now #AF6408. See the test result.
• Large sized links (18px+ and bold, or 24px+ and regular) are now #DB7900. See the test result.
  • We can use a brighter orange for the large size text because the contrast ratio requirements are not as strict.
  • I am ignoring the link color contrast checker for large links and instead using the generic contrast checker. Rationale: the link color contrast checker is specifically designed for links in body text. Page headings and navbars don't apply, if my understanding is correct.
• Buttons now use #000000 for text color. This allows us to maintain the nice bright #F7931A background color while having a strong 9.14:1 contrast ratio. See the test result.
  • Again, I used the generic contrast checker because buttons are not body text.

Notice the perfect score the ARC provides for color contrast.

Before

After

[jason-me]

I don't have time to thoroughly review all of this at the moment, but in general your statements are mostly correct and I am very happy to see you tackling this. To meet WCAG 2.1 AA Color Contrast ratio requirements, the general rule of thumb is text that is below 14pt bold or 18pt not bold must have at least a 4.5:1 contrast ratio. Text that is 14pt and bold or larger than 18pt must meet a minimum contrast ratio of 3:1 against the background. The best tool to check this manually is using: Color Contrast Checker - TPGi The only exception I am aware of is text that is part of a logo. All other text must meet these requirements.

[GBKS]

Thanks for going through this, I think this deserves more conversation. I find the darker links much harder to pick out next to the black text color, and the black text color pretty hard on the eyes. This article makes some good points on interpreting the WCAG rules, especially the one about luminance applies here. I could see the changes you made here apply more to the "prefers-contrast" mode, along with text underlines, than being the default. Let's chat on Monday about this during the jam session.

[jason-me]

With regards to discerning links by color alone, please see: https://www.w3.org/WAI/WCAG21/Techniques/general/G182

[GBKS]

Some thoughts that I'd like to discuss on this topic:

• WCAG 3 will use a new contrast method called APCA because they realized that WCAG 2 was not good enough. Tons of detail here.
• WCAG were released in 2008. Screens have improved a lot since then. iPhone screen contrast ratios have increased from iPhone 3G at 200:1 to iPhone 13 at 2,000,000:1 (latest Samsung Galaxy is even at 3,000,000:1). The difference in change in desktop screens is much lower, but still a thing. This begs the question whether lower ratios are OK because screens can reproduce color better.
• Similarly, retina screens came out in 2010, providing crisper rendering. While those are standard today in smartphones, they are not necessarily yet in desktops. Not sure how much of a consideration that is.
• Operating systems allow users to enable a "high contrast" setting, which browsers support (which also supports a "less" option...). Does that mean the default rendering of a website can be lower contrast?

Something I'd like to look into still are the details around color blindness (and other color deficiencies).

Human perception is complex, technology advances. I want us to be smart about this and not stick to an (IMHO) oversimplified and outdated set of guidelines (curious to hear an argument for them, too).

[Myndex]

Hi Stephen, Christoph and Jason @jason-me @GBKS @sbddesign

I wanted to respond to a couple of the posts, I came across this as it is linked to thread "695" in WCAG which I started some three years ago, and which led to the APCA project.

On Contrast

• I sought to meet WCAG AA. As I understand it, most websites should strive for this. WCAG AAA has very strict requirements,... I think WCAG AA is sufficient. Correct me if I'm wrong on that.

Yes, AA is a minimum, though I've been pretty outspoken as to the ways that AA is not sufficient even for "normal" vision in some cases. In particular, the WCAG 2 contrast math is not useable for "dark mode".

• Body text - I made this #000000 throughout. I don't think the subtle gray is that noticeable to most folks, and it doesn't help the links contrast at all by having the text non-black.

YAY!! The world is drowning in gray text, and that's a trend that needs to change! As I bemoaned in the article "Please Stop Using Gray Text"

Operating systems allow users to enable a "high contrast" setting, which browsers support (which also supports a "less" option...). Does that mean the default rendering of a website can be lower contrast?

Not really, WCAG 2 is the "baseline" (and it is a very low bar for the most part) things like "prefers contrast" is a user preference, that is in addition to, but does not absolve the author from basic accessibility functions, like a readable level of contrast.

CVD

With regards to discerning links by color.....

I discuss this in some detail here: ["A Discussion of Inline Links (Theory and Practice)"]{Myndex/SAPC-APCA#65)

Something I'd like to look into still are the details around color blindness (and other color deficiencies).

I've written a lot about this aspect. It splits into two parts: Readability, and distinguishability. these are both separate in terms of our neurological filtering.

Readability: for all sighted users requires the correct luminance contrast, that is, lightness/darkness contrast, and irrespective on any color — our brain processes lightness/darkness/brightness separate from color (hue/saturation). The luminance channel is where all the fine details are.

Distinguishability: such as for information coding. Luminance is good for fine details, but bad for distinguishable coding of information (i.e. levels or categories) color, as in hue/saturation, are much better for the task—except for the ~5% of the population that has a color insensitive vision issue.

So, how does readability and Distinguishability apply with color insensitive vision (CVD)?

For readability, those with CVD has normal contrast sensitivity. The exception is with the color red for those with protanopia (~1% of the population), as they lose some luminance perception of the sRGB red primary. But the mainly results in the point of "do not use red text on a black or dark background".

I discuss this in the article "What's Red and Black and also Not Read"

For distinguishability, those with CVD have difference needs and issues depending on their specific category—but it is important to remember that they are not actually "color blind", but with a deficit in some colors. (the exception there is the extremely rare achromatopsia).

I have a free tool that demonstrates the different types, including a simulation of achromatopsia/blue cone monochromacy, and you can process screenshots to show how your site may be perceived by the different types.

Myndex CVD Simulator

Thank you for reading

[GBKS]

@Myndex thank you for chiming in, and also for all the work you've done on this topic.

Not really, WCAG 2 is the "baseline" (and it is a very low bar for the most part) things like "prefers contrast" is a user preference, that is in addition to, but does not absolve the author from basic accessibility functions, like a readable level of contrast.

I think we're on the same page. We need a certain minimum. But instead of a one-size-fits-all, we can now have two sizes, one for the vast majority, and one that works especially well for the others.

We might be at a point here where we have gathered enough information and perspectives to go back to our design tools and finesse the precise solution there. We can mock up 3-5 different treatments based on standards and different design decisions, and then get consensus on which one to go for.

[mouxdesign]

Tested out the page using APAC guidelines. Since APAC also includes font wieghts in the color contrast ratios, its an interesting angle to look at. I used the tool by Myndex

I compared the text sizes from Myndex to get a rough idea of what the text sizes are on the bitcoin design homepage, without looking at the code.

It seems the basics are;

1. The larger the text the more less bold it needs to be. This would then be smaller weight on the text "design bitcoin for everyone"
2. The smaller the text the more bold the text would be better for accessibility practices (according to APAC). if the font weight of "slack" is 24px then making the text bolder would be better accessible.
   
   

With that said to get a nicer higher level of contrast on the text "bitcoin design for everyone", I am not sure a font weight of 200 would be appropriate as it lowers the contrast just from a visual perspective considerably. I would consider the APAC guidelines but use my own visual perspective as well as to what would look best. That would be somewhere in the middle. (A medium weight)

[Myndex]

And just to mention: the weights shown on the tool are with a reference font, such as Barlow or Helvetica. some fonts may differ substantially. Here's a guide to making a weight comparison to a reference font:
Myndex/SAPC-APCA#28 (comment)

[tilltonystark]

I do agree with @GBKS using pitch black (#000000) is not easy for human eyes on higher pixel displays.

[sbddesign]

This PR is stale. I am going to close it. We can take another look at #831 in the new year.