User preference to adjust diff colors for color blindness #11162

New Issue

GiteaMirror · 2025-11-02T09:29:25-06:00

GiteaMirror commented

2025-11-02 09:29:25 -06:00

Originally created by @BGlasneck on GitHub (Jul 4, 2023).

Feature Description

For red-green-blind people, the colors in a diff are difficult or impossible to distinguish.

Therefore it would be good if a user can specify in the settings that he is either color blind or can choose individual colors.

Here is an example of what a custom diff can look like.

Screenshots

No response

Originally created by @BGlasneck on GitHub (Jul 4, 2023). ### Feature Description For red-green-blind people, the colors in a diff are difficult or impossible to distinguish. Therefore it would be good if a user can specify in the settings that he is either color blind or can choose individual colors. [Here](https://userstyles.org/styles/149864/github-diff-colorblind-friendly) is an example of what a custom diff can look like. ### Screenshots _No response_

GiteaMirror added the topic/accessibility type/proposal type/feature labels 2025-11-02 09:29:25 -06:00

GiteaMirror commented

2025-11-02 09:29:26 -06:00

@delvh commented on GitHub (Jul 4, 2023):

I don't think that's the task of a setting.
Please think about adding a custom color-blind-friendly theme instead.
That will do the same thing in a non-intrusive way.
Once you have developed it, please also add a PR to https://gitea.com/gitea/awesome-gitea so that others can use it as well.

@delvh commented on GitHub (Jul 4, 2023): I don't think that's the task of a setting. Please think about adding a custom color-blind-friendly theme instead. That will do the same thing in a non-intrusive way. Once you have developed it, please also add a PR to https://gitea.com/gitea/awesome-gitea so that others can use it as well.

GiteaMirror commented

2025-11-02 09:29:26 -06:00

@silverwind commented on GitHub (Jul 4, 2023):

High-contrast theme variants is something to consider for the future, but I don't think our themeing infrastructure is there yet to support it. First we need a way to set individual "default light" and "default dark" themes, then we can talk about additional variants.

@silverwind commented on GitHub (Jul 4, 2023): High-contrast theme variants is something to consider for the future, but I don't think our themeing infrastructure is there yet to support it. First we need a way to set individual "default light" and "default dark" themes, then we can talk about additional variants.

GiteaMirror commented

2025-11-02 09:29:26 -06:00

@silverwind commented on GitHub (Jul 5, 2023):

Notably, GitHub has two variants to each theme:

High-Contrast
Color-Blind

Instead of separate theme clones, these could be options in the theme, so for example when <html> has data-colorblind=true attribute, a selector :root[data-colorblind] { --color-red: #f00} can take effect to override variables in the base theme. This way, we avoid duplicating the whole theme and still have a fallback to base colors in case the theme does not have these variants.

@silverwind commented on GitHub (Jul 5, 2023): Notably, GitHub has two variants to each theme: - High-Contrast - Color-Blind Instead of separate theme clones, these could be options in the theme, so for example when `<html>` has `data-colorblind=true` attribute, a selector `:root[data-colorblind] { --color-red: #f00}` can take effect to override variables in the base theme. This way, we avoid duplicating the whole theme and still have a fallback to base colors in case the theme does not have these variants.

GiteaMirror commented

2025-11-02 09:29:27 -06:00

@techknowlogick commented on GitHub (Jul 5, 2023):

fwiw there are many types of colour blindness: https://www.colourblindawareness.org/colour-blindness/types-of-colour-blindness/ so an enum should be used vs a bool

@techknowlogick commented on GitHub (Jul 5, 2023): fwiw there are many types of colour blindness: https://www.colourblindawareness.org/colour-blindness/types-of-colour-blindness/ so an enum should be used vs a bool

GiteaMirror commented

2025-11-02 09:29:27 -06:00

@Infinoid commented on GitHub (Jan 29, 2024):

I've been looking at this recently. Our company has multiple color-blind people, and it would be nice if the Gitea UI were more legible to them. There are a few specific areas we've run into problems. And I have a question about how themes work, versus how they SHOULD work.

There seem to be 4 classes in the Gitea UI which affect colors of buttons and status boxes and such. These are "primary", "secondary", "red" and "green". It's the "red" and "green" ones that are confusing in the context of color-blind themes.

Example: the PR page for a PR which is open but not ready to merge, rendered for an admin (who can merge anyway, overriding branch protection rules). This page has a nice "open" label near the top is marked class="ui green label issue-state-label". The merge button at the bottom is meant to look scary, and is marked class="ui buttons merge-button red".

A theme for red-green color-blind people would assign different colors to both of these.
So, would you consider a PR which added a theme that sets --color-red to grey, and --color-green to blue? Or would these class terms need to be cleaned up first, before such a PR could be approved?

In any case, I'm wondering if using qualitative words, like "good" and "bad", or maybe "ready" and "override", or "happy" and "scary" or something, would be less confusing than "red" and "green".

@Infinoid commented on GitHub (Jan 29, 2024): I've been looking at this recently. Our company has multiple color-blind people, and it would be nice if the Gitea UI were more legible to them. There are a few specific areas we've run into problems. And I have a question about how themes work, versus how they SHOULD work. There seem to be 4 classes in the Gitea UI which affect colors of buttons and status boxes and such. These are "primary", "secondary", "red" and "green". It's the "red" and "green" ones that are confusing in the context of color-blind themes. Example: the PR page for a PR which is open but not ready to merge, rendered for an admin (who can merge anyway, overriding branch protection rules). This page has a nice "open" label near the top is marked `class="ui green label issue-state-label"`. The merge button at the bottom is meant to look scary, and is marked `class="ui buttons merge-button red"`. A theme for red-green color-blind people would assign different colors to both of these. So, would you consider a PR which added a theme that sets `--color-red` to grey, and `--color-green` to blue? Or would these class terms need to be cleaned up first, before such a PR could be approved? In any case, I'm wondering if using qualitative words, like "good" and "bad", or maybe "ready" and "override", or "happy" and "scary" or something, would be less confusing than "red" and "green".

GiteaMirror commented

2025-11-02 09:29:27 -06:00

@wxiaoguang commented on GitHub (Apr 21, 2024):

-> Initial support for colorblind-friendly themes #30625

@wxiaoguang commented on GitHub (Apr 21, 2024): -> Initial support for colorblind-friendly themes #30625

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#11162