GitHub Community
GitHub Dark Mode Appearance Themes are Not Helpful #149932
Replies: 2 comments
-
|
💬 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 ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
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. ⭐ |
Beta Was this translation helpful? Give feedback.
-
|
Hello @Myndex - thank you for providing this feedback! We have filed this with our Accessibility team so that it can be reviewed and will follow-up here with any additional questions or updates. Thanks again! |
Beta Was this translation helpful? Give feedback.
-
Select Topic Area
Product Feedback
GitHub Feature Area
UI/UX
Body
On the one hand I applaud GitHub for attempting to address accessibility issues. However, I need to point out that GitHub seems to be chasing its tail or following inappropriate guidance, to GitHub's (and user's) detriment.
Dark Themes
The only dark mode theme that is marginally useful is the "high contrast" theme. The other themes present such low contrast as to be difficult or impossible to view or use.
If the WCAG 2 contrast math is being used to instruct these themes, please stop. WCAG 2 contrast assessments cannot be used for dark modes. WCAG 2 contrast is not based on any relevant vision nor readability science, and fully ignores the relevant vision and readability research of the last 25 years. WCAG 2 contrast methods do not provide salient design guidance, and there are other methods that are superior, and that exceed WCAG 2 especially for dark mode.
In particular, the use of saturated blues for dark mode links, coupled with the unsupportable addition of underlines, is anti-accessible. I am glad that the underline feature can be removed. But that does not fix the poor color choices for link text.
The problem is not showing if something is a link, it is that the text of the link is readable, and GitHub seems to ignore readability in favor of what? Someone's uninformed view that links should be hard to read? GitHub would be well advised to look toward the relevant science and research on these subjects.
CVD Themes
The important aspect of supporting color insensitive users is to provide the information by more than only color. Adding the checkmark to the "dot" is one helpful way to do this.
Beyond that, GitHub's attempts at improving accessibility for color insensitive folks is unsupported by relevant vision science. It would appear that the tactic was to adjust colors so that they appear to standard vision as the default colors might look to a particular CVD vision. But that has the reverse effect, and does not improve accessibly in any way.
In these examples, using a clinically accurate CVD simulation, the GitHub themes are either of no relevance, or actually reducing the important luminance contrast.
Moreover, it's useful to note that in light mode in particular, the hue perception is nearly non existent—this is due to the high spatial frequency of the element. Color vision for all users is at a third of the resolution of luminance, so small/thin elements have reduced hue perception.
Further, the choice to flip green to red for the CVD themes is unsupportable, and only causes confusion. Especially for Tritanopia, which has no problem distinguishing red from green, but is insensitive to changes in blue.
But again, what is important is to differentiate important information with more than color. A checkmark is a good step, but does that differentiate from a dot, as shown in these examples? I don't think so, at least not in isolation. What meaning does a dot provide?
Differentiation
A key here is differentiation vs isolated recognition. In the case of the circle/dot next to an issue post, which may be presented with no alternate state, there may be nothing to compare to—the particular state might not be obvious or understood without a comparison to other states.
In the case of link text, the link text is most often surrounded by other non-link text. Here, there only needs to be enough differentiation in appearance to indicate that a link is present. blue for links creates both a luminance as well as a hue change, that is perceivable by all vision types.
For light mode, blue will be dark like surrounding dark text, as saturated blue on a typical display contains very little luminance. But such a blue is not appropriate in dark mode, for the same reason. The blue primary on an sRGB display emits a mere 7% of the total luminance. Far too little for any reasonable, readable contrast.
As an example, assuming a black background
#000000, a minimum body text color is#cccccc, and an associated link color of#66bbffprovides both hue and luminance contrast for differentiation, while maintaining readability.To combat the poor readability of color choices by GitHub, I usually make link text bold to ensure it is still readable in dark modes here.
Note
Side Note: on the subject of black backgrounds: black can be best, depending on other design factors. The canard that black is "bad" comes from a very poor quality source, a website that promotes truly bad information. I lament about this and other poor quality information in "Please Stop Using Gray Text"
TL;DR
GitHub would do better for visual accessibility if they:
Color (hue) should enhance meaning, but never be the sole presentation of meaning.
Regards,
Andrew Somers
Director of Research
Inclusive Reading Technologies, Inc.
ReadTech Visual Contrast
Beta Was this translation helpful? Give feedback.
All reactions