starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Enable users to disable VT colors (for accessibility, visibility, contrast, etc.) #4264

New Issue
Open
opened 2026-01-30 23:42:27 +00:00 by claunia · 11 comments
claunia commented 2026-01-30 23:42:27 +00:00
Owner
Copy Link

Originally created by @bitcrazed on GitHub (Oct 5, 2019).

Description of the new feature/enhancement

Users, esp those with accessibility needs, should be able to disable command-line apps from altering text and background colors, either via API calls, or via VT sequences.

Terminal should still honor users' color theme and default foreground and background color choices, allowing users to select high-contrast etc. themes / colors if they wish.

Proposed technical implementation details (optional)

Suggest a setting called something like:

disableDynamicColors
disableAppColors

... or similar.

Originally created by @bitcrazed on GitHub (Oct 5, 2019). # Description of the new feature/enhancement Users, esp those with accessibility needs, should be able to disable command-line apps from altering text and background colors, either via API calls, or via VT sequences. Terminal should still honor users' color theme and default foreground and background color choices, allowing users to select high-contrast etc. themes / colors if they wish. # Proposed technical implementation details (optional) Suggest a setting called something like: ``` disableDynamicColors disableAppColors ``` ... or similar.
claunia commented 2026-01-30 23:42:28 +00:00
Author
Owner
Copy Link

@egmontkob commented on GitHub (Oct 5, 2019):

This is a great initiative; however, I don't think it's as simple as disabling coloring escape sequences.

My main concern is that doing this without QAing and tailoring each and every application in this mode (which is clearly not going to happen, unless that guy volunteers 😄) will often result in unusable behavior, even for users with perfect sight. For example, Midnight Commander highlights the currently focused file by using other colors; and the currently selected (toggled) ones with yet another. If you simply drop coloring, you can no longer track where your cursor is. For black and white UI's, e.g. the mail client pine, chances are that the app uses reverse mode for its highlighted item, so at least that mode should be preserved as a means of switching the colors, but it's still not a generic solution.

Back to mc in particular: This app does have an explicit command line flag to work in black in white (actually 4 grayscale values by using the normal and bright counterpart of both). It does have some serious usability issues though (certain pieces of text being invisible, while certain other things just not getting highlighted). I can't recall any relevant bugreport, suggesting that this feature is hardly ever used on today's graphical terminals, if at all.

There's an initiative no-color.org to address black and white on the application side, using a common approach. The page also includes a list of apps supporting and not supporting it, as well as a list of equivalent command line flags or config options for them. I do have concerns about this particular proposal, though, and I'm not alone. However, per-application support is the only viable approach I can see in order to get black and white only (i.e. not even grayscale – if that's what you really want), I can't see how the terminal could automatically create a usable black and white version of applications.

I have so far seen three different major features offered by terminals, to help the poor sighted:

  • Minimum contrast. For each character cell, the foreground color is modified if necessary to be farther away(*) from the background, according to a slideable setting. It's implemented at least by macOS's default Terminal.app, and if I remember correctly, iTerm2 too.

    (*) Preferably using a sophisticated formula rather than the Pythagorean distance in RGB space which allegedly has hardly anything to do with the human-perceived distance; or even multiple formulas for multiple kinds of typical problems, such as red-green vs. blue-yellow color blindness.

  • Increased line spacing (and perhaps column spacing, too). This is implemented by VTE (geez, it was much trickier than anticipated with tons of corner cases) and quite a few others.

  • Some kind of screen reading. This is implemented by VTE, and I guess Konsole too.

Other ideas could also be brainstormed. Here's one that occurred to me right now, combining multiple previous ones.

Add some line and column spacing. Convert all the colors to grayscale. Make sure that the foreground's gray is far enough from the background's for each cell. Moreover:

A potential problem with this is that two backgrounds that are quite different in RGB, conveying the message of switching to another UI item, can now be almost identical, placed next to each other. To mitigate the problem: make the background color of a charcell (the grayscale variant thereof) extend to the gap between cells if and only if the neighboring cell in that direction has the very same original RGB value, or if the grayscale colors are far away. Otherwise, when two different RGBs mapped to almost the same gray, draw a separator line in the gap that is quite different from the neighboring cells' colors.

I have no idea how useful it is, might be worth it creating a mockup screenshot or demo implementation.

All in all, I think this is a topic which requires heavy input from those affected to understand what their preferences are, and also is subject to feasibility since e.g. there's no magic wand to convert apps' output to only black and white in a usable way.

@egmontkob commented on GitHub (Oct 5, 2019): This is a great initiative; however, I don't think it's as simple as disabling coloring escape sequences. My main concern is that doing this without QAing and tailoring each and every application in this mode (which is clearly not going to happen, unless [that guy](https://youtu.be/KMudkRcwjCw?t=1652) volunteers :smile:) will often result in unusable behavior, even for users with perfect sight. For example, `Midnight Commander` highlights the currently focused file by using other colors; and the currently selected (toggled) ones with yet another. If you simply drop coloring, you can no longer track where your cursor is. For black and white UI's, e.g. the mail client `pine`, chances are that the app uses reverse mode for its highlighted item, so at least that mode should be preserved as a means of switching the colors, but it's still not a generic solution. Back to `mc` in particular: This app does have an explicit command line flag to work in black in white (actually 4 grayscale values by using the normal and bright counterpart of both). It does have some serious usability issues though (certain pieces of text being invisible, while certain other things just not getting highlighted). I can't recall any relevant bugreport, suggesting that this feature is hardly ever used on today's graphical terminals, if at all. There's an initiative [no-color.org](https://no-color.org/) to address black and white on the application side, using a common approach. The page also includes a list of apps supporting and not supporting it, as well as a list of equivalent command line flags or config options for them. [I do have concerns](https://github.com/MidnightCommander/mc/pull/133) about this particular proposal, though, and [I'm not alone](https://news.ycombinator.com/item?id=17244313). However, per-application support is the only viable approach I can see in order to get black and white only (i.e. not even grayscale – if that's what you really want), I can't see how the terminal could automatically create a usable black and white version of applications. --- I have so far seen three different major features offered by terminals, to help the poor sighted: - Minimum contrast. For each character cell, the foreground color is modified if necessary to be farther away(\*) from the background, according to a slideable setting. It's implemented at least by macOS's default Terminal.app, and if I remember correctly, iTerm2 too. (\*) Preferably using a sophisticated formula rather than the Pythagorean distance in RGB space which allegedly has hardly anything to do with the human-perceived distance; or even multiple formulas for multiple kinds of typical problems, such as red-green vs. blue-yellow color blindness. - Increased line spacing (and perhaps column spacing, too). This is implemented by [VTE](https://bugzilla.gnome.org/show_bug.cgi?id=781479) (geez, it was much trickier than anticipated with tons of corner cases) and quite a few others. - Some kind of screen reading. This is implemented by VTE, and I _guess_ Konsole too. Other ideas could also be brainstormed. Here's one that occurred to me right now, combining multiple previous ones. Add some line and column spacing. Convert all the colors to grayscale. Make sure that the foreground's gray is far enough from the background's for each cell. Moreover: A potential problem with this is that two backgrounds that are quite different in RGB, conveying the message of switching to another UI item, can now be almost identical, placed next to each other. To mitigate the problem: make the background color of a charcell (the grayscale variant thereof) extend to the gap between cells if and only if the neighboring cell in that direction has the very same original RGB value, or if the grayscale colors are far away. Otherwise, when two different RGBs mapped to almost the same gray, draw a separator line in the gap that is quite different from the neighboring cells' colors. I have no idea how useful it is, might be worth it creating a mockup screenshot or demo implementation. --- All in all, I think this is a topic which requires heavy input from those affected to understand what their preferences are, and also is subject to feasibility since e.g. there's no magic wand to convert apps' output to only black and white in a usable way.
claunia commented 2026-01-30 23:42:28 +00:00
Author
Owner
Copy Link

@egmontkob commented on GitHub (Oct 5, 2019):

Re minimum contrast: see also https://github.com/microsoft/terminal/issues/2638#issuecomment-527281295.

@egmontkob commented on GitHub (Oct 5, 2019): Re minimum contrast: see also https://github.com/microsoft/terminal/issues/2638#issuecomment-527281295.
claunia commented 2026-01-30 23:42:28 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Oct 5, 2019):

It's worth mentioning that Windows already has a bunch of built-in accessibility filters for different forms of color blindness, grayscale, inverted colors, etc. I don't know if that's enough for most people, or if it's preferable to be able to control that sort of thing on a per-app basis.

@j4james commented on GitHub (Oct 5, 2019): It's worth mentioning that Windows already has a bunch of built-in accessibility filters for different forms of color blindness, grayscale, inverted colors, etc. I don't know if that's enough for most people, or if it's preferable to be able to control that sort of thing on a per-app basis.
claunia commented 2026-01-30 23:42:28 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Oct 8, 2019):

Yeah, this is a huge workitem -- I'm moving it out from v1.0 to the backlog and marking it for the specification tracker. Thanks everyone for your input!

@DHowett-MSFT commented on GitHub (Oct 8, 2019): Yeah, this is a huge workitem -- I'm moving it out from v1.0 to the backlog and marking it for the specification tracker. Thanks everyone for your input!
claunia commented 2026-01-30 23:42:29 +00:00
Author
Owner
Copy Link

@DrorHarari commented on GitHub (May 8, 2022):

As a legally blind person less than 10% of the vision nerve remaining, the WindowsTerminal is painful to use because of the mess different apps cause with character cell coloring where it is hard to distinguish between the background and the foreground colors (both in terms of color combination as well as luminosity).

Any solution, however primitive/ugly/temporary/experimental will be hugely appreciated. Finesse can come later.

Coloring is supposed to add another dimension to the text - currently it comes at the major cost of making text invisible to us unfortunate ones. It will be more beneficial to lose the extra dimension of highlighting specific parts of the text, than the lose text.

A first attempt where the background is always the terminal background (ignoring the character background) and the foreground is the basic colors with the most contrast (darkest on white backround and lightest on black background) will maket things much better.

@DrorHarari commented on GitHub (May 8, 2022): As a legally blind person less than 10% of the vision nerve remaining, the WindowsTerminal is painful to use because of the mess different apps cause with character cell coloring where it is hard to distinguish between the background and the foreground colors (both in terms of color combination as well as luminosity). Any solution, however primitive/ugly/temporary/experimental will be hugely appreciated. Finesse can come later. Coloring is supposed to add another dimension to the text - currently it comes at the major cost of making text invisible to us unfortunate ones. It will be more beneficial to lose the extra dimension of highlighting specific parts of the text, than the lose text. A first attempt where the background is always the terminal background (ignoring the character background) and the foreground is the basic colors with the most contrast (darkest on white backround and lightest on black background) will maket things much better.
claunia commented 2026-01-30 23:42:29 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 9, 2022):

@carlos-zamora, @PankajBhojwani and I were just having a discussion on this topic actually. We will likely want to follow up with you with some ideas in the near future 😄

@zadjii-msft commented on GitHub (May 9, 2022): @carlos-zamora, @PankajBhojwani and I were _just_ having a discussion on this topic actually. We will likely want to follow up with you with some ideas in the near future 😄
claunia commented 2026-01-30 23:42:29 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (May 9, 2022):

It's worth mentioning that all the DEC color terminals actually had a setting for switching between different color modes - one of the choices being "monochrome". On the VT340 and VT525 this could also be controlled via the DECSTGLT escape sequence, which I'm hoping to implement at some point.

As I understand it, the monochrome mode would disable all SGR colors, so the only text attributes would be things like bold/bright, underline, reverse, etc. I'm not sure if that's exactly what you want here, but it's perhaps worth considering, because then we would just be reusing a standard function rather than having to invent something new.

@j4james commented on GitHub (May 9, 2022): It's worth mentioning that all the DEC color terminals actually had a setting for switching between different color modes - one of the choices being "monochrome". On the VT340 and VT525 this could also be controlled via the `DECSTGLT` escape sequence, which I'm hoping to implement at some point. As I understand it, the monochrome mode would disable all SGR colors, so the only text attributes would be things like bold/bright, underline, reverse, etc. I'm not sure if that's exactly what you want here, but it's perhaps worth considering, because then we would just be reusing a standard function rather than having to invent something new.
claunia commented 2026-01-30 23:42:29 +00:00
Author
Owner
Copy Link

@DrorHarari commented on GitHub (May 9, 2022):

... "monochrome" ... I'm not sure if that's exactly what you want here, but it's perhaps worth considering...

Yes, this is definitely a good standard way to make sure a screen is readable regardless of what color/contrast crimes were committed. A good start.

@DrorHarari commented on GitHub (May 9, 2022): > ... "monochrome" ... I'm not sure if that's exactly what you want here, but it's perhaps worth considering... Yes, this is definitely a good standard way to make sure a screen is readable regardless of what color/contrast crimes were committed. A good start.
claunia commented 2026-01-30 23:42:29 +00:00
Author
Owner
Copy Link

@carlos-zamora commented on GitHub (Oct 27, 2022):

@DrorHarari we relatively recently messed with the adjustIndistinguishableColors profile setting: https://github.com/microsoft/terminal/pull/13512

If you haven't used it yet, I think it might be up your alley. 😊

@carlos-zamora commented on GitHub (Oct 27, 2022): @DrorHarari we relatively recently messed with the `adjustIndistinguishableColors` profile setting: https://github.com/microsoft/terminal/pull/13512 If you haven't used it yet, I think it might be up your alley. 😊
claunia commented 2026-01-30 23:42:30 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Oct 27, 2022):

FYI, one of our long-term plans for this feature is to allow for an adjustable contrast ratio. Users who need higher contrast text will be able to crank it up (and/or we'll automatically do it if the system is in High Contrast mode globally), and folks who don't need contrast to be quite so harsh can lower it. :)

@DHowett commented on GitHub (Oct 27, 2022): FYI, one of our long-term plans for this feature is to allow for an adjustable contrast ratio. Users who need higher contrast text will be able to crank it up (and/or we'll automatically do it if the system is in High Contrast mode globally), and folks who don't need contrast to be quite so harsh can lower it. :)
claunia commented 2026-01-30 23:42:30 +00:00
Author
Owner
Copy Link

@DrorHarari commented on GitHub (Oct 28, 2022):

Thanks Carlos - that's great news.

I have installed the latest preview but could not see any difference at all
(including in cases with very low differences):

no-diff-color-handling

@DrorHarari commented on GitHub (Oct 28, 2022): Thanks Carlos - that's great news. I have installed the latest preview but could not see any difference at all (including in cases with very low differences): ![no-diff-color-handling](https://user-images.githubusercontent.com/1831901/198532083-19ef2202-bef4-4053-a0c8-6647ee29419f.jpg)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Accessibility Area-Rendering Area-Settings Area-VT Issue-Feature Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#4264
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?