Terminal: Enable users to disable VT colors (for accessibility, visibility, contrast, etc.)
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:
disableAppColors
... or similar.
bitcrazed
All 4 comments
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 :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 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
on 5 Oct 2019
Re minimum contrast: see also https://github.com/microsoft/terminal/issues/2638#issuecomment-527281295.
egmontkob
on 5 Oct 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
on 5 Oct 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
on 8 Oct 2019
Related issues
DieselMeister
·
3Comments
TayYuanGeng
·
3Comments
waf
·
3Comments
mdtauk
·
3Comments
miniksa
·
3Comments
Most helpful comment
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 :smile:) 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.