Do not exclusively use color to convey information

[manuhabitela]

Describe the problem to be solved

👋

The goal of this issue is to track all issues concerning the exclusive usage of color to convey information. This is something we should not do, according the WCAG, the international accessibility guidelines.

Context is:

Color only should not be used to convey info. For example, an "online status" badge being shown with a green background when online, and a red background when offline, is not enough: If I have trouble distinguishing colors, it'll hard for me to understand if I'm online or not. To fix this example, I could change the text to "online" or "offline", or add an icon that changes (with a crossed wifi icon when offline).

Sources:

https://www.w3.org/WAI/WCAG21/Understanding/use-of-color

Describe the solution you would like

Here are the issues I noticed for now that we can discuss:

• in the documents list, switching between list view and gallery view can be misleading. Current viewing mode is shown only with a color change of the buttons. Since there are only two buttons, it can be tricky to understand which is enabled. And the current color issues makes it so that the two colors are not contrasted enough. I can have trouble noticing a color change. Here, adding a background and/or a border would fix the issue.
• we can argue toggle buttons can be difficult to understand. Which visual state means "enabled" and which means "disabled"? We could imagine adding a checkbox icon when the button is enabled.
• same feedback could be made on grouped buttons (that act as radio inputs). When choosing between 3 choices and more the issue is not as pronounced; but when choosing between 2 choices, the question remains: which is enabled, which is disabled?
• the Table/Column tabs are misleading from my point of view. The inactive tab has bold text and bg color matching current tab content, while the active tab has an accent background color. Talked about here already, added a screenshot with a clearer idea from my pov.

Screenshots:

• 
• 
• 
• 
• 
• 
• 

There are not a lot of issues I think, and they are easy to fix :)

Will add more elements to this issue when I stumble upon more.

[tayflo]

Hello there :wave: If I might share my humble opinion, as an enthusiastic Grist user:

1. I perfectly agree that List/Gallery views buttons, in document list, right now have an enabled/disabled state which is only conveyed through colors which are not distinctive/contrasted enough from each other, and that should be fixed.

2. I also agree that the Table/Column tabs might feel misleading when starting using Grist and even after that (especially the bold on the inactive tab). Your proposition, resulting in this approved proposal is indeed clearer in my opinion.

3. I'm not so sure about the toggle buttons tho. When an information is based on background-to-foreground-switching (with sufficient contrast between background and foreground, e.g. dark-on-light to light-on-dark), it is not "only conveyed through color", as there are sufficient contrast to make the distinction between the two states (it's the same for point 2 tho, but I still find your proposal clearer).

This last point is mentioned in the WCAG guideline you quoted itself:

If content is conveyed through the use of colors that differ not only in their hue, but that also have a significant difference in lightness, then this counts as an additional visual distinction (...). Similarly, if content is distinguished by inverting an element's foreground and background colors, this would pass (again, assuming that the foreground and background colors have a sufficient contrast).

So to me the problem here is not really about "conveyed only by color", but more, as you state it, how to know which correspond to "enabled" and which correspond to "disabled" (and it affects users independently of potential visual deficiencies or colorblindess).

It is arguable but generally speaking I don't find it too confusing that light-on-dark means "enabled" whereas dark-on-light means "disabled", in an interface where things are generally dark-on-light.

It might maybe be improved tho. Below are some ideas about how to achieve that. I will take examples from the Material Design (a rulebook and resource pack for software design which is developped by Google through open-source repo, is used by many, and champions accessibility as a core principle).

1. The solution you mention: add a supplementary icon on the button. I'm not sure I'm a big fan of this option, I feel like it might clutter a bit the interface.

   Nonetheless, it is an option considered in Material Design for selected elements (for enabled elements, a light-on-dark pattern is used, but I think it might be "enabled" in opposition to inactive/unclickable elements); here is how it looks like:

   

2. Another solution would be to add an inner shadow to elements. But since the elements are already very dark, I don't feel like it is achievable here. Or both "enabled" and "disabled" states should be light-on-dark, with "enabled" state with an inner shadow (or with an homogeneous sufficiently-darker background, as in the examples (1) and (2) right above), in place of the foreground-background inversion.

3. The last solution I think of would be to limit the dark-background to a subset of the selector; that is, keep the original border and keep a light margin (same tone for each elements in the selector) around the dark background. That way, the selected element is clearly a subset of the selector, whereas non-selected elements looks within the broarder frame of the selector.

   Here is how it looks like in Google Docs (without foreground-background inversion tho):

   

   And a very not-nice representation of mine of the idea on the TextBox/Spinner selector :-)

   

Additionnal notes about properly handling color accessibility

• I was wondering if colorblindness was mainly about hue rather than lightness and saturation, so I double-checked. It seems to be the case, but lightness and saturation can also enter in play (that's why in the end, what matters is contrast between colors). For instance ligh-yellow or light-turquoise could be hardly distinguishable from white, and dark-red or dark-blue from black. (Sources: tools listed below, Wikipedia, testimonials on Reddit, Quora...)

• Some tools and techniques can be used. Wikipedia lists some usual techniques.

• There are some ways to help building color palettes which are adapted to colorblind people:

  • Some pre-defined palettes exist (e.g. Viridis).

  • The HCT color space from Material Design is thought to help build constrated-enough color palettes.

  • This little tool also checks for "color-blind safety" when generating gradient.

  • The tailwind.ink tool may also be interesting.

• There are some ways to help visualising and check designs against that:

  • A quick (but imperfect) way to check for contrast is to switch on grayscale on one's monitor or operating system (imperfect because not only hue is implied, see the first point I mentioned in this section).

  • There are tools to visualize how an image might look for colorblind people, such as on daltonlens.org and myndex.com.

  • There are tools built-in in design softwares and browsers. For instance you can turn this on on Firefox.

• There are also tools to check for contrast between colors; already listed in issue #1243.

[manuhabitela]

Hey, thanks for all your input, it's greatly appreciated :)

Yeah the whole color contrast stuff is sometimes not that straightforward. Current WCAG calculations also have their limits. This article is interesting if you are curious.

[lusebille]

Link to mocks https://www.figma.com/design/wcpetFt6aOKzTszcvPPWLQ/%5B05%2F24%5D-Grist-Design?node-id=2438-131024&t=qX4iHFYd8uzsW8kZ-1