Repository navigation
Idea for improving visibility of labels #10400
Description
Describe the feature or problem you’d like to solve
When using gh issue list, I discovered that labels with light colors are hard to see on a light terminal, and dark labels are hard to read on a dark terminal. This can be seen with gh issue -R spenserblack/test-repo list
Proposed solution
To improve visibility, I believe it would be best if the background color was the label's color, and the foreground text would be either white or black. When the label is a dark color, the text should be white, and when the label is a light color, the text should be black. This is how labels work on the GitHub website AFAIK.
Additional context
Some light terminal themes swap white and black, and some do not. So, for best compatibility with theme colors, truecolor (RGB) ansi escapes should be used to make sure that black text and white text is in fact black and white. I.e. it's better to use \033[38;2;0;0;0m rather than \033[30m.
There are many potential ways to detect if a color is light or dark to pick a good contrasting color. In my research and experience, I've found that calculating relative luminance works best. The basic idea is that green accounts for the majority of perceived light, and blue accounts for the least amount. This is why white text is hard to read and black text is easy to read on a #00FF00 background, and yet the exact opposite is true on a #0000FF background, even though they appear equally intense if you just look at the numbers. I've found that using the formula here works very well for determining if a color is light or dark and picking an appropriate contrasting color. This might not be inclusive to users with color-blindness, though 🤔
Activity
BagToad commentedon Feb 11, 2025
@andyfeller I'm wondering if this relates at all to your accessibility investigations?
andyfeller commentedon May 1, 2025
@spenserblack : with
v2.72.0release of accessibility public preview improvements, the GitHub CLI will use default color text when displaying labels rather than the 24-bit RGB hex codes unless you enable the newcolor_labelsconfiguration settings.This might not be ideal as you state we could attempt to calculate the closest ANSI 4-bit color for a given 24-bit true color, however there are no guarantees if this is contrasting enough for users.
So, I'd love your thoughts about this new feature and where the GitHub CLI might iterate on it to provide a better experience! 🙇
spenserblack commentedon May 2, 2025
This is absolutely awesome! I love the
accessible_colorsfeature, and I think disabling/enablingcolor_labelsreally does help a lot.The only thing I can think of is that, if someone enables
color_labels, they can still hit a dark-on-dark or light-on-light low contrast issue, which can be resolved by picking an appropriate contrasting background. But this isn't a big concern IMO since color labels can be disabled.I don't think
ghhas this problem, but I just wanted to share this: from personal experience, I've learned that for best compatibility it's best to always avoid explicitly setting text to either black (\e[30m) or white (\e[37m). Especially because light themes can be unpredictable: some swap black and white, and others don't. So if you're ever planning on using an ANSI 4-bit color for white text, it's better to use the default color.neofetchhad a special case to remap white to\e[0mIIRC, for example.But, overall I think this has been handled amazingly well, and IMO this can be closed unless anyone else thinks there's more work to be done.
spenserblack commentedon May 2, 2025
Oops, looks like I spoke a bit too soon 😅
I just got a chance to switch over to a light-themed terminal, and enabled
accessible_colors. When I rangh repo view <USER>/<REPO>, the text was... white on white. The ANSI colors were black-on-white, but the terminal theme I was using reversed the black and white colors, making the actual colors white-on-white. Some popular light themes do this: gruvbox is one of them. And yet not all light themes reverse black and white.Based on what I'm seeing, it looks like the executable is possibly querying the terminal's background color, and selecting if it should make the markdown paragraph text black or white depending on that background color? While displaying ANSI black text when the background is light might be seem reasonable, the fact that some themes reverse black and white complicates things 😅
So, yeah, like said above, I think maybe you'd want to show colorless text rather than selecting either black or white, for best compatibility.
graelo commentedon Feb 7, 2026
Hi, I have the same issue.
I'd suggest to an
accessible_color_overridesmap in~/.config/gh/config.ymlthat lets users remap individual semantic color roles to ANSI indices 0–15:Only specified roles would be overridden; all others keep their defaults. The overrides would be ignored when
accessible_colorsis notenabled. Invalid values (outside 0–15) would produce a warning on stderr.I guess this would also mean introducing
GH_ACCESSIBLE_COLOR_OVERRIDES.This builds directly on the infrastructure from your PR @andyfeller #10820 — it could be a small incremental change that makes the feature work for a wide range of terminal setups.
Wdyt ?