Not all color schemes are legible #46
Comments
|
Heads up: this would be affected by #11... it's not clear (at present) that all templates use the colors for the same purposes - despite what the styles spec says... for example Bash often prefers 16 colors in 2 sets of 8 colors with light and dark variants - and I think we should better cater to that possibility in the future. I think this issue may be conflating different things though:
I don't see what's wrong with a "Black and White" theme that was Other than (my perhaps misunderstood) requirement that themes have "multiple distinct colors" I can easily get behind all the rest of your ideas with regards to accessibility. I think APCA is the future here though: https://github.com/Myndex/apca-w3 And then you have to ask yourself what becomes of all the non-accessible themes? Also (just to be clear) accessibility isn't a yes/no based on only color pairs... font-size matters a LOT... so someone might have a zany theme and if they use it at 52px font-size... it's perfectly accessible... so you can't TRULY talk about accessibility in terms of color alone. WCAG 2.1 recognizes this some and APCA goes even further in recognizing this explicitly. So if we were to start mandating accessibility here we'd also have to decide a "minimum" font size in order for us to have any basis to declare many themes truly bad or good... Often what is "accessible for all" at various sizes may start to seem overly high-contrast to many... so I'm not sure we should mandate accessibility. If someone wants to design a low-contrast theme, more power to them... but perhaps in our index of themes we should call out which are most accessible or have a flag for those that reach a certain standard of accessibility - to make it easier for users to filter. |
|
(For the purpose of this comment, I'll be referring to the set of 16 colors defined by these files as "palettes", for clarity)
I wasn't aware of this ticket, I haven't had a chance to read through it yet but I'll check it out in a bit.
That approaches the problem I'm trying to illustrate. Without clear guidelines, the template authors cannot effectively use the colors. The styling guidelines are a "contract" that enable template authors and palette authors to design independently. Without them, how would the template author know to use
Distinctiveness is an accessibility issue. The colors are used to represent semantically distinct things (e.g. "Comment" vs "Variable" vs "Keyword") as well as UI elements (e.g. status bars, tab colors, selected-text background, etc.). Your two-tone color scheme would render many UI elements literally indistinguishable from the background. To have a "statusbar" you would at least need three colors (application background, status bar background, text). Not to mention, you haven't described how a template author could be aware of which of the 16 belong to which of the two visibly distinct colors.
I haven't heard of this, I'll have to add it onto my color-theory research pile.
Personally? I would simply remove the ones that can't be corrected (and produce themes with e.g. foreground elements indistinguishable from the background), and deprecate the ones that are functional but inaccessible (for whatever "deprecate" might mean). But I wanted to leave the actual enforcement up to the maintainers/users. I'm mainly interested in establishing a clear, defined standard for what the 16 colors should actually represent.
I wasn't aware of ACPA, but I did read WCAG 2.1 and it specifies a minimum contrast ratio for "large-scale text and images of large-scale text" of 3:1. The only things that have no minimum contrast ratio are "incidental text" ("pure decoration") or "text that is part of a logo or brand name". All other text, according to the guidelines, have a minimum contrast ratio of 4.5:1. Either of those contrast ratios seem reasonable lower bounds to me (certainly, the base16-schemes itself has no control over the font size of the programs. there's no saying which colors e.g. iterm2 will decide to use for tiny text, so it would be reasonable to say that all colors combinations should clear the minimum contrast ratio requirement for regular text)
As mentioned above, non-"Large-scale" text has a standard minimum-contrast-ratio requirement (per WCAG 2.1) so no minimum font size requirement would be required. (I haven't read ACPA yet)
Surely, there would have to be some minimum contrast requirement. Would a color scheme defined entirely between
That is mostly what I was alluding to in the OP. By "programmatic" and "tests" I only meant that this process should be defined in code (as tests run against each palette), rather than as a brittle, manual process. I didn't mean to suggest that failing palettes should be automatically denied or removed. |
Semantic colors help with that... template authors should TRUST the scheme authors... if we had the ability for a scheme to say:
Then the template should trust that... one of the problems right now if that we don't give scheme authors enough ability to communicate intent to template authors. For example there is no great way to map our 16 colors to 16 color terminals - because our style spec doesn't speak to absolute hues at all...
We may just have to disagree here... but I can at least tell you my understanding of these terms:
If I can't read it at all, it's inaccessible. If I can read it but it's just hard to tell a variable from a function that's less usable. I'm not interested in the argument, I just wanted you to understand my perspective - maybe it helps.
Well obviously the status bar could be the application background.. I've seen this in several themes... so the TWO colors that matter are fg/bg... but I wasn't really arguing for "two colors" as much as I was that mono-thematic (greyscale, bluescale, etc) should still be entirely and I don't think they are "less accessible" than more colorful schemes - if the contrast from FG/BG was good. At that point it's a preference - and I don't think we should deny people preference (in themes).
Semantic colors solves that I think. This is also possible with the current guide... just set all FG items (and all 8 accent colors) to white and all "BG" items to black... if you wanted to support seach/selected you'd need a greyscale inbetween... I never suggested that the colors have zero semantic meaning- I'm aguing for the opposite - that they have MORE semantic meaning. |
Can you give me a few examples of the worst offenders here? So I can look them up... n/m I went thru your original issues and see you often cited examples. |
You have to read ACPA... all the scores there have no meaning without adjusting for the font size... so to have a scale and give thumbs up / thumbs down we have to specify a specific "blessed" font size... That can be decided, I was only pointing out it's not exclusively about color pairs. |
I don't believe in policing (with rules) the stupidly obvious. People should submit a snap or two when submitting new themes... if it's all a single color-ish and we can't read anything, we reject that theme. We don't need a rule for this, it's just common sense. IMHO. I haven't really seen this though, so this feels like a strawman unless you're about to provide examples? |
|
A realized it might be more helpful if I addressed yoru common issues:
As already stated I think this is a schemes choice. I don't think we should mandate that
I think this is a guideline, not an absolute. If they were the same, that's fine. If a theme only has a singular BG/FG, that's fine. Now if dark foreground is lighter, that's a bit strange and more worthy of discussion. I'm not sure (at first blush) if we should enforce this though as perhaps a theme is an "inverted" theme where it's purposely doing the opposite of what you expect.
It is not my understanding that this is mandated at all. I don't believe it should be.
I think it's a guideline, not a rule.
We don't make this guarantee (other than perhaps default fg/bg)... though it's a fair question if we should... I think it's not clear at all what the rules for "Light Foreground (Not often used)"
This is not mandated. Some people like this "look".
Hues are not mandated by the style at all (though they are sadly, remarkably consistent). I think this should be solved with semantic colors instead to allow the theme designer to specify how they feel their theme should be mapped to terminal colors. Matching is not always the goal. It's entirely possible a terminal scheme wishes to not match ANSI colors at all intentionally. |
|
If I had a suggestion here it would be to start with something simple, say measuring baseline accessibility... and write an automated tool for that... and then you could slowly add "optional" checks to that tool and as a community we could then decide which of the "optional" checks was worth making mandatory (whatever that means) and which weren't... But work on the tool itself could being before any of the tiny details was decided... what about a few rules for starters:
And immediately you'd have something super useful for measuring the baseline accessibility of the entire ecosystem... I'd want to have a tool like this in place before we starting making changes to the style guidelines to address this kind of thing... I'd want to know how many of our existing themes meet the new proposed guideline, etc... as I think that might give us pause or at least educate our decisions. IE, if we have a great new idea but then we look and 99% of our themes would be in violation of the new rule, then either the new rule is bad or we need to have a version serious discussion about all those themes. |
|
(tl;dr at the end)
It wasn't clear to me that's what you were referring to. I see now you're proposing that additional aliases be allowed going forward so that templates can more accurately map colors to relevant elements. I won't comment on that proposal for now, but it would not substantially change this issue (re: invalid/illegible schemes), beacuse this is referring to schemes that currently misbehave, and would still need to be corrected. In the case that the proposal in #11 is accepted, this issue (#46) can be simply understood to affect existing schemes for the "backwards compatibility" adaptations mentioned
Sorry, but you said "two literal colors" and specified "
...
Perhaps you misunderstood what I was referring to as "distinct colors". I wasn't talking about hues, I meant literally 16 visually distinguishable My point was that:
Sure, in the very specific case of a status bar, it's possible to substitute the status bar background for the application background. But obviously this is not the only thing So that is a big assumption that is very obviously wrong for many templates. Many of the UI elements in
Again, I had not actually read your proposal at the time I wrote my reply (which I mentioned). But having read it, the "unbinding of semantics with aliasing" would only be relevant for schemes and templates going forward. All current templates expect
"Common sense" requires some mutual agreement as to what the basic parameters are. We can't seem to agree on what those parameters even are so I'm skeptical of deferring to "common" sense.
I don't understand what this means. A "scheme" (referring to the palette of 16 colors) *has no control over how the colors are used downstream, and it's not clear to me (perhaps even less clear, after this discussion) what exactly a template can rely on, so how could the color scheme possibly know what they are "choosing"? Is the template not free to use
If that is the case, it should be clear. Because there are templates that use the graduations in perceived lightness to communicate information. If we can't promise that it should be made clear to consumers of the color schemes that they can't depend on this.
To be frank, it should either be a rule or not mentioned at all. What is the point of an optional "guideline" if the consumers of the schemes can't actually depend on them?
I'm not just talking about preference. I'm saying that consumers of these color schemes (i.e. application templates), expect that colors be visually distinguishable. There's currently no requirement that app templates be functional in the case that If we're not going to guarantee that certain colors actually be distinguishable (even by a computer! not even talking about human perception!), then that should be made clear so that consumers of the schemes can know to avoid those color pairs, or those specific color schemes tl;dr:
Perhaps I derailed this discussion from the beginning by mentioning the "accessibility" issues and associated tests. We can't begin to approach that issue when there are basic aspects that are functionally broken Downstream consumers of these color schemes (i.e. templates) need to know which pairs of colors they can use to represent things that not only should but need to contrast. e.g.: foreground text from background text, selection from background, search result We need to establish that either:
At the moment, the only schemes that work consistently across most of the templates I've found look like this:
* (i.e. can be distinguished from each other by the human eye) any deviation may result literally broken interfaces. My main suggestion is that the actual requirements be codified so that template authors can design the interfaces of their applications whithout making invalid assumptions. |
I'm saying more than that though... I've seen some themes that purposely only want to highlight specific syntactic elements, like only strings, keywords, and comments... they are very minimal on purpose... so that would only require 3 of the 8 "distinct" values and if a theme wanted to do that, I think that would be their choice. If someone didn't like such minimalism, they shouldn't use that theme.
Yes, but I'm not sure this is the huge point you think it is. It seems impossible to be any other way. If some templates follow some of the guidelines and some themes follow some and then you aggregate ALL the templates - yes, you're going to be left with a case where the only schemes that look good in ALL templates are the "lowest common denominator" - ones that tried to read every guideline as a rule. I'm not so sure that (with the current spec) that all schemes should look good in a all templates. Again, the example of someone using Base16 to craft true 16-color terminal schemes (which don't have 8 foreground and background colors)... that is very likely to only work well (at the moment) with a singular template. Should we then say these aren't Base16 schemes and the template is not a Base16 template? I'm not sure. I think you'd lean towards yes and I'd lean towards no. This is a big question that needs to be answered... are people pushing the boundaries welcome in the community or are they outside the spec? I do think some of this can be solved with semantic colors... (but think we may have to let go of requiring 8 fg/bg colors per palette).
No, clearly that shouldn't be allowed in the short-term... but I think it wouldn't matter in the LONG term.... in the long term (if we go semantic aliases) then 1-16 are just numbers of the palette, no slot would have any specific meaning at all... if you wanted the base background color you'd say
I do see your point but I'll point out again just one dimension: creativity... you could say in the spec: "for the best usability colors 8-16 should be visually distinct and often use different hues"... and I think that's a GREAT idea/guideline for most themes... but someone who WANTS a very minimal theme with only a few colors... I think if they do that they shouldn't be "kicked out" or "not base16"... perhaps we need a new word or phrasing to describe schemes that follow ALL the guidelines perfectly...?
True, but what is your suggestion again for those themes? I don't think either of us can fix them all overnight (short of removing them, which I don't think is practical)... I'm merely trying to work on the path forward so if someone said "hey this theme is broken" they would have the tools available to make a PR and fix it, etc... I think there may be more agreement than disagreement but I feel like you're saying/implying:
And I'm more like:
The latter feeling less "legalistic" to me... and doesn't require any immediate action against all the legacy themes...
Yes, I gave you a few minimal starter rules... I think the only things you can (minimally) GUARANTEE contrast against are:
I'm tempted to add some more of the other FG/BG variants, but I think it's important to first have a starting point... if we wrote (and ran) the test above and found out 99% of themes are in compliance, then we could add more rules... But if only 80% are in compliance with such a simple expectation then I think we need to stop and say: Is this a rule or not? IE, add one rule at a time vs "making everything that's mentioned now a solid rule". I'll try to drop off here a bit though and we should allow for some more voices here... these are just my and your opinions... we need more input. |
I'm not saying that all schemes should "look good", that's purely subjectively. I'm not even saying that they should all strictly accessible. My point is that, when a user decides to install the base16 schemes for their IDE/editor/utility/etc., they should never completely break the user interface. I figured it was reasonable to expect that switching to a color scheme would not make it impossible to read the app's menu items, but apparently that's too high a bar?
A scheme doesn't get to choose how the colors are used! The project, by design, does not give the color schemes any tools to designate that X color should be used for Y elements. They literally cannot provide that information as is. So I really don't understand what you mean when you talk about "choice". How can a color scheme possibly know that "specific syntactic elements" are going to be conflated? As you said, they're only "guidelines", so there's no possible way for the color scheme to know that "base08 is used for strings and base0A is used for comments so those two can be the same color". That is simply not something it can guarantee.
I don't actually care about how things are enforced. I just want the standards to be clear. That's literally it. You could choose not to enforce it! If the standard is "anything goes really", then there's absolutely no point to any of this. A template author that has to write individual templates for each color might as well just write their app configurations manually. Which is what everyone does anyways (e.g. solarized, gruvbox, dracula, etc.) |
Well, obviously that's a pretty poor outcome... I think our difference may be in how do we prevent that. I wonder if some of these checks shouldn't be at the TEMPLATE level, not the scheme level... if Base16 stays so generalized (as it is now)... it may be that some schemes just aren't suited for application X or Y... we could detect that at build-time and exclude those themes from those applications. It's possible one of the schemes that tears up your application makes a great Terminal theme... This would be an entirely different approach, solving the problem from a different angle... the template can assume a LOT of fg/bg pairing that may not be guaranteed, but then it's the templates job to "bow out" if it seems that the final product it's building it just ridiculous.
Sure it does (even if not perfectly). The spec itself does that by assigning semantic meaning to certain colors (I'm largely speaking about 8-16).
Is that what we're getting hung up on - the absoluteness of it all? Obviously many/most themes follow the "guidelines/rules/whatever" regarding the semantic meaning of 8-16...Other than fg/bg mostly all your left with is 8-16... and I'd say those trend more into "rules" territory than "lighter FG must be lighter than FG" does. They kind of have to since otherwise templates are mapping nothing other than fg/bg colors... So in those (majority) cases those themes are absolutely choosing how the colors are used. Well, the spec is - if we're being pedantic... not everything I say should be taken 100% literally... obviously a template is 100% in control of output... but the spec itself gives the schemes power to say "i want diff deleted to be GOLD!"... by virtue of the contract (even if not absolute) with templates via the spec. |
|
Do you code in Javascript? If I open up the work I've done over in #26 would you be interested in adding in rules you feel as "important" and then we could start to get a better picture of where everything stands other than one-off examples? We'd need to figure out how to "score" a scheme, but as soon as we did that you could start collecting higher-level stats on which schemes matched which set of rules, etc... might be helpful for a discussion of which guidelines to tighten or loosen...
Out of curiosity which app/apps are you using? |
This seems wholly reasonable, but I don't see an example of this listed in your common issues (sorry if I miss it)... It's obvious that the potential (of all these individual issues) might lead to this (and I understand the desire to attack the problem at a high level)... but do you have some examples of a scheme/template combo that's literally "completely broken" because of these issues? I think it could be helpful to open a few individual issues of such [terrible] brokenness and see what could be done to fix them on a case-by-case basis (while this larger issue simmers). And screen shots might help for those of us that don't have the specific applications in question installed so we can't just easily open up the themes and see how they look, etc... This would also help educate us about how we should deal with such cases when we do have a way to discover them in a more automated fashion... (as you're suggesting here) Update: It seems clear that just saying "this scheme doesn't follow all the guidelines of the spec" alone doesn't create a "completely broken" experience... that's only possible when a template assumes a guideline is a MUST and then uses a fg/bg combo that breaks (with certain schemes)... hence the request to identify individual broken scheme/template combos. |
joshgoebel
added
enhancement
|
I'm going to close this for now, because I don't think we have much of a plan to fix this at the moment - schemes have been user provided for a long while, and some of them just end up being more legible than others. If there are issues with specific schemes, I think it would be great to bring those up with the scheme authors, or show examples and fix them in the schemes repo. |
A common problem I have when switching between color schemes is that many color pairs are not always legible. Text is often unreadable on certain backgrounds, or common assumptions about the relationships between colors is not consistent (making it difficult to set color rules in applications which correspond to each other; e.g. progressively darker backgrounds)
Common issues:
blueforest,brogrammer,cupertino,edge,nova, etc.brogrammer,gruvbox-material-light-hard,papercolor-light,ia-light,material-palenightblueforest,codeschool,darkviolet,picoheetch-light, ...tokyodark, ...onedark,google-dark,one-light, ...pinkyare swappedideas:
The text was updated successfully, but these errors were encountered: