starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-24 16:05:21 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Default palette is unreadable #1676

New Issue
Closed
opened 2026-01-30 22:33:28 +00:00 by claunia · 8 comments
claunia commented 2026-01-30 22:33:28 +00:00
Owner
Copy Link

Originally created by @alabuzhev on GitHub (Jun 14, 2019).

image

Hi,

https://devblogs.microsoft.com/commandline/updating-the-windows-console-colors/

Why Change the Entire Color Scheme?

During the past 20 years, screens & display technology, contrast ratio, and resolution have changed significantly, from CRT’s through TFT LCD’s to modern-day nano-scale 4K displays.

The legacy default scheme was not built for modern displays and does not render as well on newer high-contrast LCD displays. This is particularly apparent with deeply saturated darker colors like blue.

The new default colors will modernize the look of the Windows Console and make it more congruent with other terminal experiences, such as the integrated terminal in VSCode.

I've read the article and I'm not convinced.

Why? See the picture.

The colours that were different (and supposed to be different) are almost indistinguishable now.
I'm not colour blind and my display is not CRT, but I don't see much difference between Teal and Blue or Green and Lime or Silver and White anymore (here and below I'm using the names from this table). It's hard to tell which of them is on the Black background. It's hard to read one on another.

Note that Teal and Green are "dark" colours, while Blue and Lime are "light" colours.
Combinations of light and dark are supposed to be readable by definition, and they actually were, since the Big Bang or so.

I especially like that the article states that blue is "very difficult to read" on black, with screenshots (presumably influenced by a weird dark-on-dark vim colour scheme?)
To be clear: \033[1;34 in the example is not Blue, it's Navy.
Both Black and Navy are "dark" colours, each supposed to be used with a lighter colour, but not with each other.
It's not surprising that dark on dark was not so readable.
Unreadable light on dark and dark on light surprise me much more.

I dare say that the default console palette is now broken. Even Windows 98 (!) palette is more readable.

P.S. I know about colortool, console window properties, shortcut properties, defaults, registry settings etc., thanks. The problem is that users don't know (and don't want to know) and keep filing the same issue - "the colours are suddenly ugly & unreadable" - as they migrate to Windows 10.

Originally created by @alabuzhev on GitHub (Jun 14, 2019). ![image](https://user-images.githubusercontent.com/11453922/59516410-31604f00-8eb9-11e9-8fd6-1362ae4874eb.png) Hi, https://devblogs.microsoft.com/commandline/updating-the-windows-console-colors/ > ### Why Change the Entire Color Scheme? > During the past 20 years, screens & display technology, contrast ratio, and resolution have changed significantly, from CRT’s through TFT LCD’s to modern-day nano-scale 4K displays. > > The legacy default scheme was not built for modern displays and does not render as well on newer high-contrast LCD displays. This is particularly apparent with deeply saturated darker colors like blue. > > The new default colors will modernize the look of the Windows Console and make it more congruent with other terminal experiences, such as the integrated terminal in VSCode. I've read the article and I'm not convinced. Why? See the picture. The colours that were different (and supposed to be different) are almost indistinguishable now. I'm not colour blind and my display is not CRT, but I don't see much difference between Teal and Blue or Green and Lime or Silver and White anymore (here and below I'm using the names from [this table](https://en.wikipedia.org/wiki/List_of_software_palettes#Microsoft_Windows_default_16-color_palette)). It's hard to tell which of them is on the Black background. It's hard to read one on another. Note that Teal and Green are "dark" colours, while Blue and Lime are "light" colours. Combinations of light and dark are _supposed to be readable by definition_, and they actually were, since the Big Bang or so. I especially like that the article states that blue is "very difficult to read" on black, with screenshots (presumably influenced by a [weird dark-on-dark vim colour scheme](https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/16776103-blue-color-is-too-dark)?) To be clear: `\033[1;34` in the example is not Blue, it's Navy. _Both_ Black and Navy are "dark" colours, each supposed to be used with a _lighter_ colour, but _not with each other_. It's not surprising that dark on dark was not so readable. Unreadable light on dark and dark on light surprise me much more. I dare say that **the default console palette is now broken**. Even Windows 98 (!) palette is more readable. P.S. I know about colortool, console window properties, shortcut properties, defaults, registry settings etc., thanks. The problem is that users don't know (and don't want to know) and [keep](https://forum.farmanager.com/viewtopic.php?f=36&t=11430) [filing](https://forum.farmanager.com/viewtopic.php?f=36&t=11350) [the](https://forum.farmanager.com/viewtopic.php?f=4&t=11384) [same](https://forum.farmanager.com/viewtopic.php?f=9&t=11200) [issue](https://forum.farmanager.com/viewtopic.php?f=9&t=10948) - "the colours are suddenly ugly & unreadable" - as they migrate to Windows 10.
claunia added the Issue-QuestionArea-SettingsResolution-AnsweredProduct-Meta labels 2026-01-30 22:33:28 +00:00
claunia commented 2026-01-30 22:33:30 +00:00
Author
Owner
Copy Link

@VictorVG commented on GitHub (Jun 16, 2019):

👍

Visually, the new palette is composed of optically non-contrast color pairs, which leads to increased operator fatigue and increased control errors. The palette used since Windows XP in this sense is more successful, although it makes sense to increase the number of color gradations available in it to sRGB.

@VictorVG commented on GitHub (Jun 16, 2019): :+1: Visually, the new palette is composed of optically non-contrast color pairs, which leads to increased operator fatigue and increased control errors. The palette used since Windows XP in this sense is more successful, although it makes sense to increase the number of color gradations available in it to sRGB.
claunia commented 2026-01-30 22:33:30 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 18, 2019):

@mscraigloewen might be able to chime in here.

@zadjii-msft commented on GitHub (Jun 18, 2019): @mscraigloewen might be able to chime in here.
claunia commented 2026-01-30 22:33:30 +00:00
Author
Owner
Copy Link

@craigloewen-msft commented on GitHub (Jun 19, 2019):

I'll attempt to summarize and address your feedback, please let me know if I've misrepresented anything!

9/3, 3/9, 10/2, 2/10, 15/7 and 7/15 used to be readable but now are not.

The colour palette was designed using the WCAG AA guidelines to assess the accessibility of the text. You can view the guideline reference and check contrasts using this handy web tool.

In the case of the colour combinations you put above, none of them meet accessibility or readability standards in the 'Windows NT palette' or prior, and this hasn't changed in the new colour palette.

It's harder to distinguish between the colours like dark green and light green (2 and 10) in the new palette

This is very valid feedback! The 'Windows NT palette' is actually the same as a high contrast palette, as its colours are as high value as they can be (e.g: Red is 255,0,0 and dark blue is 0,0,128). The new colour scheme was created partly to address feedback that the dark colours on the black background were unreadable. For example, dark blue on black has been popularly used in the Windows Subsystem for Linux. This new colour scheme improves the contrast of all dark colours on a black background, and makes dark blue and and dark cyan accessible. Additionally, the new scheme lowers the contrast of the 'bright' colours to make the colour scheme easier on the eyes to read for a long period of time. Both of these can affect the indistinguishably of the colours, and is ultimately a balancing act with different users having different preferences.

Judging unreadability

Ultimately, we need a way to judge whether the new scheme is 'unreadable' or not, and the best judge for this is the WCAG AA guidelines. By these standards, the new palette improves accessibility for 'dark colours' on the black background while maintaining accessibility for the light colours.

Your feedback is helpful for us for looking how we can further improve this scheme! And from your post script I hope that making the settings in easy to manage in the Windows Terminal and Windows Console can go a long way to helping users change the colour scheme to a preferred one.

@craigloewen-msft commented on GitHub (Jun 19, 2019): I'll attempt to summarize and address your feedback, please let me know if I've misrepresented anything! ## 9/3, 3/9, 10/2, 2/10, 15/7 and 7/15 used to be readable but now are not. The colour palette was designed using the WCAG AA guidelines to assess the accessibility of the text. You can view the guideline reference and check contrasts using this [handy web tool](https://webaim.org/resources/contrastchecker/). In the case of the colour combinations you put above, none of them meet accessibility or readability standards in the 'Windows NT palette' or prior, and this hasn't changed in the new colour palette. ## It's harder to distinguish between the colours like dark green and light green (2 and 10) in the new palette This is very valid feedback! The 'Windows NT palette' is actually the same as a high contrast palette, as its colours are as high value as they can be (e.g: Red is 255,0,0 and dark blue is 0,0,128). The new colour scheme was created partly to address feedback that the dark colours on the black background were unreadable. For example, dark blue on black has been popularly used in the Windows Subsystem for Linux. This new colour scheme improves the contrast of all dark colours on a black background, and makes dark blue and and dark cyan accessible. Additionally, the new scheme lowers the contrast of the 'bright' colours to make the colour scheme easier on the eyes to read for a long period of time. Both of these can affect the indistinguishably of the colours, and is ultimately a balancing act with different users having different preferences. ## Judging unreadability Ultimately, we need a way to judge whether the new scheme is 'unreadable' or not, and the best judge for this is the WCAG AA guidelines. By these standards, the new palette improves accessibility for 'dark colours' on the black background while maintaining accessibility for the light colours. Your feedback is helpful for us for looking how we can further improve this scheme! And from your post script I hope that making the settings in easy to manage in the Windows Terminal and Windows Console can go a long way to helping users change the colour scheme to a preferred one.
claunia commented 2026-01-30 22:33:30 +00:00
Author
Owner
Copy Link

@alabuzhev commented on GitHub (Jun 23, 2019):

Hi Craig, thanks for your response!

none of them meet accessibility or readability standards in the 'Windows NT palette' or prior, and this hasn't changed in the new colour palette

Quite possibly - I'm not a graphic designer and I can't judge whether or not they meet any standards. The feedback is all about personal perception.

The new colour scheme was created partly to address feedback that the dark colours on the black background were unreadable. For example, dark blue on black has been popularly used in the Windows Subsystem for Linux.

Does that imply that dark blue on black is perfectly readable in Linux?

Let's have a look:

image

Debian Linux TTY1: Dark Blue: 0 0 170
Debian Linux Konsole: Dark Blue: 24 24 178
It's just a little bit brighter than NT (0 0 128) and I find it hard to believe that for Linux folks 16%-darker blue was a disaster.

the best judge for this is the WCAG AA guidelines

Quoting https://www.w3.org/WAI/standards-guidelines/wcag/:

The WCAG documents explain how to make web content more accessible to people with disabilities

I believe we have a slightly different situation here:

  • The content is not for web
  • The target audience is everyone.

Conceptually we live in a quite limited Universe with only 16 distinct colours.
When your space is so limited, the high contrast is not a choice, it's a necessity.
If you go on a long trip and your backpack has room only for 16 items, would you take 16 similar things? Probably no.
Same here - if you only have 16 colours, you want them to be different, because making them too similar would effectively reduce 16-colour palette to 8-colour.

Your feedback is helpful for us for looking how we can further improve this scheme!

Thanks for considering improving it!

To summarise:

  • light/dark colours in several pairs (green, white, magenta) are too close to each other
  • cyan has too much blue component in it - dark cyan is way too close to light blue (note that cyan is an additive colour and so by definition should have about the same amount of green and blue in it)
  • light yellow is too close to white

making the settings in easy to manage in the Windows Terminal and Windows Console can go a long way to helping users change the colour scheme to a preferred one.

Definitely!

I understand that Microsoft has invested time and effort into the new palette and it has its audience, but there are lots of people who were staring daily at those classic colours for decades and learnt to love them (and the same with people coming from Linux).

ColorTool is a good tool, but it's not out-of-the-box and not so user-friendly.
Having a convenient UI for something so user-visible as color schemes is a must have.

@alabuzhev commented on GitHub (Jun 23, 2019): Hi Craig, thanks for your response! > none of them meet accessibility or readability standards in the 'Windows NT palette' or prior, and this hasn't changed in the new colour palette Quite possibly - I'm not a graphic designer and I can't judge whether or not they meet any standards. The feedback is all about personal perception. > The new colour scheme was created partly to address feedback that the dark colours on the black background were unreadable. For example, dark blue on black has been popularly used in the Windows Subsystem for Linux. Does that imply that dark blue on black is perfectly readable in Linux? Let's have a look: ![image](https://user-images.githubusercontent.com/11453922/59978062-4a12e800-95d0-11e9-8174-3280ecc5c82b.png) Debian Linux TTY1: Dark Blue: 0 0 170 Debian Linux Konsole: Dark Blue: 24 24 178 It's just a little bit brighter than NT (0 0 128) and I find it hard to believe that for Linux folks 16%-darker blue was a disaster. > the best judge for this is the WCAG AA guidelines Quoting https://www.w3.org/WAI/standards-guidelines/wcag/: > The WCAG documents explain how to make web content more accessible to people with disabilities I believe we have a slightly different situation here: - The content is not for web - The target audience is everyone. Conceptually we live in a quite limited Universe with only 16 distinct colours. When your space is so limited, the high contrast is not a choice, it's a necessity. If you go on a long trip and your backpack has room only for 16 items, would you take 16 similar things? [Probably no](https://youtu.be/LqQ1YssGRh4?t=93). Same here - if you only have 16 colours, you want them to be different, because making them too similar would effectively reduce 16-colour palette to 8-colour. > Your feedback is helpful for us for looking how we can further improve this scheme! Thanks for considering improving it! ### To summarise: - **light/dark colours in several pairs (green, white, magenta) are too close to each other** - **cyan has too much blue component in it - dark cyan is way too close to light blue** (note that cyan is an additive colour and so by definition should have about the same amount of green and blue in it) - **light yellow is too close to white** > making the settings in easy to manage in the Windows Terminal and Windows Console can go a long way to helping users change the colour scheme to a preferred one. Definitely! I understand that Microsoft has invested time and effort into the new palette and it has its audience, but there are lots of people who were staring daily at those classic colours for decades and learnt to love them (and the same with people coming from Linux). ColorTool is a good tool, but it's not out-of-the-box and not so user-friendly. Having a convenient UI for something so user-visible as color schemes is a must have.
claunia commented 2026-01-30 22:33:30 +00:00
Author
Owner
Copy Link

@craigloewen-msft commented on GitHub (Jun 24, 2019):

Thanks for the follow up! I think your summary is full of great points on how the default colour scheme could be improved.

@craigloewen-msft commented on GitHub (Jun 24, 2019): Thanks for the follow up! I think your summary is full of great points on how the default colour scheme could be improved.
claunia commented 2026-01-30 22:33:31 +00:00
Author
Owner
Copy Link

@kepstin commented on GitHub (Jul 22, 2019):

Just to note that I've run into similar issues when looking at a new default colour scheme for gnome-terminal.

There's a lot to think about in the color scheme design - including supporting both light and dark terminal background colors, and the fact that existing applications will often pick their own foreground and background color combinations. You can't optimize contrast for every combination applications have used, but you should try to make common combinations as good as possible.

In particular, I ended up leaving dim and bright blue both as fairly dark colours. The dim blue (navy) over default background has basically never been readable when the background is dark, so most applications avoid that combination. It doesn't need high contrast. Similarly for bright yellow text over default background - it has never been readable on light-background terminals.

But various color combinations - especially yellow and cyan over dim blue - are fairly common. In the classic CGA/VGA palette cyan is very much brighter than blue, making this very readable. The new windows palette loses contrast there.

I used as reference things like the vim default palette (dark/light - as an aside, you really need to add a bg color query terminal escape to the new ms terminal so vim can pick an appropriate palette automatically!) and applications using "midnight commander" style palettes, like mc itself or htop. (Note that these screenshots are from during development - based on them, I decided to switch to a brighter/greener cyan and a brighter dim purple in the final version.)

@kepstin commented on GitHub (Jul 22, 2019): Just to note that I've run into similar issues when looking at a [new default colour scheme for gnome-terminal](https://gitlab.gnome.org/GNOME/gnome-terminal/issues/72). There's a lot to think about in the color scheme design - including supporting both light and dark terminal background colors, and the fact that existing applications will often pick their own foreground and background color combinations. You can't optimize contrast for every combination applications have used, but you should try to make common combinations as good as possible. In particular, I ended up leaving dim and bright blue both as fairly dark colours. The dim blue (navy) over default background has basically never been readable when the background is dark, so most applications avoid that combination. It doesn't need high contrast. Similarly for bright yellow text over default background - it has never been readable on light-background terminals. But various color combinations - especially yellow and cyan over dim blue - are fairly common. In the classic CGA/VGA palette cyan is very much brighter than blue, making this very readable. The new windows palette loses contrast there. I used as reference things like the vim default palette ([dark](https://www.kepstin.ca/dump/gnome-terminal-20190310/vim-dark-16color.png)/[light](https://www.kepstin.ca/dump/gnome-terminal-20190310/vim-light-16color.png) - as an aside, you really need to add a bg color query terminal escape to the new ms terminal so vim can pick an appropriate palette automatically!) and applications using "midnight commander" style palettes, like [mc itself](https://www.kepstin.ca/dump/gnome-terminal-20190310/mc-light.png) or [htop](https://www.kepstin.ca/dump/gnome-terminal-20190310/htop-light-mc.png). (Note that these screenshots are from during development - based on them, I decided to switch to a brighter/greener cyan and a brighter dim purple in the final version.)
claunia commented 2026-01-30 22:33:31 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 10, 2022):

You know, there's some solid discussion in here, but at the end of the day, I don't think we're likely to be changing the default palette for the console & Terminal again. The Terminal is far more flexible in the ability to customize it than the console ever was. The palette we have today is certainly passable. Plus, the terminal ships with a variety of schemes by default, so changing it to something else isn't terribly challenging.

I'm gonna close this one out. Thanks all!

@zadjii-msft commented on GitHub (Jan 10, 2022): You know, there's some solid discussion in here, but at the end of the day, I don't think we're likely to be changing the default palette for the console & Terminal again. The Terminal is far more flexible in the ability to customize it than the console ever was. The palette we have today is certainly passable. Plus, the terminal ships with a variety of schemes by default, so changing it to something else isn't terribly challenging. I'm gonna close this one out. Thanks all!
claunia commented 2026-01-30 22:33:31 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 29, 2024):

(for folks that were following this thread: you may want to head on over to #17818)

@zadjii-msft commented on GitHub (Aug 29, 2024): (for folks that were following this thread: you may want to head on over to #17818)
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-Settings Issue-Question Product-Meta Resolution-Answered
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#1676
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?