The new, darker blue in links

[GoldenretriverYT]

Select Topic Area

Product Feedback

Body

I noticed that the blue in links got darker. This reduces the contrast between the background and foreground in the dark mode. Whilst personally it only looks bad imo, it definitely reduces accessibility.

[fwcd]

(Moved from #51251)

Yes, the default color of links (--color-accent-fg) of the default dark theme has recently changed from #58a6ff to #3f84e4, which can be quite a bit harder to read than the previous version (on black background), especially when lots of other bright colors are present nearby. Compare the new theme:

to the older one:

I think at least having the option to switch back to the old color would be great for accessibility.

[AndrejMitrovic]

For anyone else bothered by this, here's a Tapermonkey script that reverts some of the colors:

// ==UserScript==
// @name         Github
// @namespace    http://tampermonkey.net/
// @version      0.1
// @description  try to take over the world!
// @match        https://github.com/*
// @grant        none
// ==/UserScript==

function addGlobalStyle(css) {
    var head, style;
    head = document.getElementsByTagName('head')[0];
    if (!head) { return; }
    style = document.createElement('style');
    style.type = 'text/css';
    style.innerHTML = css;
    head.appendChild(style);
}

(function() {
    'use strict';

    addGlobalStyle('* { --color-accent-fg: #58a6ff !important; }');
})();

Does anyone know the previous hex colors of the other UI color elements which changed? It seems like the normal grey text color has also changed.

[AndrejMitrovic]

Just realized this doesn't fix the links, only the top bar. Well, someone who's more versed in CSS can probably figure out a better solution.

[simurai]

Hmm... Not sure about Tapermonkey, but the CSS should work. Also with just using body:

body {
  --color-accent-fg: #58a6ff !important;
}

Before	After

Note that the variable --color-accent-fg will change in the future. Probably to --fgColor-accent.

[pauldps]

Thanks for this. The darker blue was giving me headaches. (Using Dark high contrast theme.)

[shadoath]

Where are the Github color variables defined, how can I find other values?

[simurai]

Yes, I agree that the link color in the dark theme is harder to read. But we're somewhat limited in our options. 😞

The WCAG 2.0 accessibility rules state that the link color needs a contrast ratio of 3:1 against the surrounding text. Which leaves us with almost no wiggle room. Here a tool to test the contrast triangle.

Some options:

1. Make text color white #fff. Then brighten the link color a bit. Downside: This could be too bright and jarring to read in a darker enviroment.
2. Make background color black #000. Then the links are a bit easer to see against the darker background. Downside: Doesn't help that much since the link color is unchanged and also increases text vs background contrast that could be too much.
3. Brighten link color, but since it will not pass the 3:1 contrast ratio, we would need to also add underlines to all links. Downside: The underlines could feel a bit busy and cluttering the UI. Might be ok for long-form text, like a blog, but maybe less for a "web app" with a more compact UI.

Has anyone come across a great solution for blue links on a dark background that is fully accessible?

[AndrejMitrovic]

Does this tool take into account that the human eye is less sensitive to certain light wavelengths (colors)? I can't see any mention of it on the author's blog post.

Here's a quote from a page discussing human vision:

The human eye is much more sensitive to yellow-green or similar hues, particularly at night, and now most new emergency vehicles are at least partially painted a vivid yellowish green or white, often retaining some red highlights in the interest of tradition.

Maybe it's the combination of factors of the dark theme + darker shades of blue that makes this less visible for some people.

[Myndex]

Hi @AndrejMitrovic

...Does this tool take into account that the human eye is less sensitive to certain light wavelengths (colors)?...

Tool is using the standardized WCAG 2.0 contrast math. It uses the draft sRGB matrix to calculate luminance, which is spectrally weighted similar to human vision, using the CIE 1931 2° standard observer, though it is well known that the CIE 1931 does have some errors and like most colorimetry is an approximation.

The bigger problem is that WCAG 2.0 contrast math is not perceptually uniform across the visual range so when one color is black the error can be as much as 250%.

As far as blue is concerned, pure blues should always be the darkest of a color pair, particularly if it's relating to text and you want it to be readable. Please see this page by Larry Arend when he was at NASA.

Against Black, the blue ideally is no darker than #33bbff and #77d7ff.

[AndrejMitrovic]

That's great info, thanks for sharing this!

[Myndex]

Hi @simurai

Brighten link color, but since it will not pass the 3:1 contrast ratio, we would need to also add underlines to all links. Downside: The underlines could feel a bit busy and cluttering the UI.

The 3:1 for this use case is actually not part of the 1.4.1 SC (it is mentioned in the understanding document), and it doesn't really have much scientific support, and I include here 1.4.11 which does list 3:1, but has no peer reviewed empirical support as it only cites an informal email and a self-referential unpublished draft.

Visual task of differentiation is not all the same as the visual task of fluent readability. Dr. Arditi lamented the lack of useful empirical evidence supporting things such as 3:1 ratios in his 2017 paper Rethinking ADA Signage. (It's partly due to the problems described in this paper that I made readability research my current focus).

Has anyone come across a great solution for blue links on a dark background that is fully accessible?

One of the big decisions to make here is the trade off between readability and link distinguishability, as the two are in conflict. Nevertheless there are ways to design around that and improve both. I have some draft discussion on the subject, please mind it's a fairly early draft: Myndex/SAPC-APCA#65

[simurai]

Another option might be to switch to the Dark dimmed theme in the Appearance settings:

Dark Default	Dark dimmed

Since the Dark dimmed theme is not used as default, it doesn't need to follow accessibility rules and therefore can have a lighter link color.

[Myndex]

The new dark mode appears in some ways worse than the old dark mode, I'm still only able to use the high contrast dark mode.

This blog post: 2023-03-28-light-and-dark-theme claims an improvement but it appears that it actually is a de-enhancement, and an accessibility fail. Notice that I made the URL bold in an attempt to make it more readable.

IMPORTANT

WCAG 2 contrast math cannot calculate for dark mode

It's incapable of that and this is well known and well documented. WCAG 2 contrast was put forth circa 2007, a time when sites had light backgrounds and dark text, and dark mode was rare.

WCAG 2 contrast was never empirically tested, was not peer-reviewed, and essentially cherry picks references from some obsolete standards and an informal conference paper. It was objected to by IBM and other stakeholders but was pushed forward anyway.

There are perceptually uniform methods that can be used today for dark mode that are actually accessible.

LAW

There is a small faction of individuals who are claiming "you have to do WCAG 2 because it's law", but that's not exactly true, and there are legal exceptions depending on jurisdiction, particularly for alternate facilitation and for using a different method that's a demonstrated improvement.

Also, WCAG2 only requires a single version to comply (or if using an automated mode like a media query then the default modes for each media query that is not directly user settable), all other, alternate versions can be using any method desirable. And what is desirable is actual accessibility.

Claims that one should be using WCAG 2 for dark mode are misinformed.

Actual accessibility is what is legal, and actual accessibility should be the goal, not enslavement to arbitrary numbers that have no empirical evidence nor peer review to support them.

For information regarding the current state of the art, here is a peer reviewed article on the topic: Realities And Myths Of Color And Contrast the article describes many of the misunderstandings on this topic and presents useful guidance for moving forward.

Thank you for reading,

Andy

Andrew Somers
_{Color Scientist @ Myndex Research
W3C Invited Expert & WCAG 3.0 Co-Author
Any opinions expressed herein are mine and do not necessarily reflect those of the W3C.}

[sagarjs]

I am a partially visually impaired coder and use firefox to override the text and link colors.
This doesn't seem to be working in this case though.

I am not sure if some update has broken this but this is a nice way to allow users to pick their own colors.

[cehfisher]

Hello @GoldenretriverYT - thank you for providing feedback about the link color in dark mode! As @simurai pointed out in their comment the blue link color meets current WCAG color contrast ratio recommendations, even if as @Myndex highlights in their comment there are potentially issues with the way we currently measure color contrast.

We can file this issue as a feature request with the Accessibility team. While we can’t guarantee immediate action on every piece of feedback, rest assured that we are attentive to your suggestions and always striving to enhance the GitHub experience for all of our users (cc @queenofcorgis)

[Myndex]

Hi @simurai

"...The WCAG 2.0 accessibility rules state that the link color needs a contrast ratio of 3:1 against the surrounding text. Which leaves us with almost no wiggle room..."

WCAG 2.0 doesn't actually say that in the normative part of the SC (1.4.1). What 1.4.1 states is that information must not rely solely on color (hue/chroma). The understanding docs may indicate 3:1 as a way to pass 1.4.1, but there is no empirical or peer-reviewed support for that—especially as that is relying on the WCAG2 contrast math, which does not follow human perception in a useful way.

Dark Secrets of WCAG 2

WCAG 2.0 contrast math breaks down to unusable values when backgrounds are darker than about #bbbbbb. In other words, don't use WCAG2 for dark mode, it is harmful to readability. And this is especially true for individuals with color vision deficiency.

The science of vision is well established; saturated blues and reds should be the darkest of a color pair. For an sRGB display, blue makes up only 7% of luminance, red 22%, and green 71%. (In P3 red is 24%, green 69%). That's for standard human vision. For some color insensitive types, such as protanopia, the sRGB red makes up a mere 10% of total luminance. This clearly presents issues in dark mode, and WCAG2 does not address these issues.

All of this is academic—and yet ignored by WCAG 2

WCAG 2 does not promote actual accessibility. If there is some desire to "meet" WCAG_2, it should be only for a light mode scheme. And then, you only need one scheme for WCAG2 compliance. All the other schemes can instead support actual accessibility.

GitHub seemed to be on a good path to actual accessibility a few years ago, but this last year, visual accessibility has dropped. What happened? I am visually impaired, and have a tough time using this site. All of the color schemes here are non-accessible to me, except partly for "dark mode high contrast", which itself has issues I have to live with as the "least bad" choice. You have a lot of different schemes, but what is the basis for them?

Years ago we demonstrated that WCAG 2 contrast methods can be harmful to readability. This is not to diminish the other aspects of WCAG, but when it comes to visual accessibility, WCAG_2 is far from authoritative. Unfortunately, standards organizations move at a glacial pace so future corrections are on an indefinite timeline. But WCAG_2 is not the only standard available for guidance.

Thank you for reading,

Andrew Somers
Director of Research
Inclusive Reading Technologies, Inc.
APC Readability Criterion

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐