Repository navigation
Enable users to disable VT colors (for accessibility, visibility, contrast, etc.) #3066
Description
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.
Activity
egmontkob commentedon 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 Commanderhighlights 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 clientpine, 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
mcin 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 commentedon Oct 5, 2019
Re minimum contrast: see also #2638 (comment).
j4james commentedon 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.
DHowett-MSFT commentedon Oct 7, 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!
[-]Enable users to disable VT colors[/-][+]Enable users to disable VT colors (for accessibility, visibility, contrast, etc.)[/+]DrorHarari commentedon 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.
zadjii-msft commentedon May 9, 2022
Carlos Zamora (@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 😄
j4james commentedon 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
DECSTGLTescape 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.
DrorHarari commentedon May 9, 2022
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.
carlos-zamora commentedon Oct 27, 2022
Dror Harari (@DrorHarari) we relatively recently messed with the
adjustIndistinguishableColorsprofile setting: #13512If you haven't used it yet, I think it might be up your alley. 😊
DHowett commentedon 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. :)
DrorHarari commentedon Oct 27, 2022