Status page: revisit color scheme for the progress bar in the migration details page

[jaimergp]

Originally posted by @h-vetinari in https://github.com/conda-forge/conda-forge.github.io/issues/2137#issuecomment-2294793097

• [x] Migration details table colors, tooltips and visibility:
  • [x] https://github.com/conda-forge/conda-forge.github.io/pull/2239

I commented on the colour scheme changes elsewhere already, but I wanted to reiterate here that I don't see how various shades of grey are more accessible (e.g. for vision-impaired people)

than the much more distinct colours we had previously

I picked the colours from the bubbles[^1] and put them into aremycolorsaccessible (found by random googling as I was looking for turbo, more below), and while I can't vouch for their methodology, it has pretty clear opinions:

I'm certainly not a web developer, nor expert for UX and accessibility, but I do remember how google developed a new colormap (called "turbo") with accessibility in mind a while back, and naïvely taking that as a reference would seem like we should if anything have starker colours rather than more subdued ones:

Taking the values {0.0, 0.2, 0.4, 0.6, 0.8, 1.0} from their colourmap would give us 6 colours that are in some ways ideally spaced across various metrics (e.g. across various vision impairments, for details see article).

[^1]: because it's hard for me to tell where e.g. --ifm-color-emphasis-600 is actually defined; some colours are defined in custom.css, but not all

[jaimergp]

I'll reply to @h-vetinari here:

For context, what we were trying to move away from was this situation:

We could argue that the new palette with grays (which was suggested by @GabrielaVives looking at the issue from a "semantic color" point of view; e.g. green = success, red = error, almost everything else is an intermediate state that should have no colored label), makes this part hard to distinguish:

But that's why they have additional affordances like text and tooltips. Instead of focusing on color only [^1], maybe it's easier to add other resources to help distinguish those UI elements:

• Borders in the stacked bar
• Texture and/or backgrounds
• Shape and/or icons

[^1]: We can refine the distance between the grays if you so they have greater contrast among them, but it's tricky because we need to make it work in dark+light mode, and in toggled+untoggled button states. If we want to go color, then we need colorblind assessments and other details on top of those four variables. A better strategy would be use other indicators beyond color, like texture and labels (Tania also hinted at this).

In general, I'll just say this will get increasingly difficult with more colors, so let's think outside the box and focus on what information we want to present:

• Buttons to toggle certain parts of the table
• Some sort of progress bars to show the "volume" of each category quickly

---

If you want further information, this is what Tania and Sylvain shared with me in our CZI grant catch ups:

@trallard commented:

Both palettes shown in the comments screenshots are failing contrast requirements since they need not only to have at least a 4.5:1 contrast against the background colour but also against the adjacent colour (for example the green vs the dark grey AND the light grey).

There are a few things that can be done if you want to make this more accessible though

1. For this graph in particular that could be worked around by adding a border between the segments of the stacked bar (akin to the border you have added to the baubles on the green chips, if anything, within the chips the light grey should have a black border vs a white one as it currently stands as it has a low contrast)
2. There are indeed three shades of grey used, but there is not enough of a shift among those to make them distinctive enough (you might need to tweak the saturation and brightness to make a starker difference, but also from experience, anything over 4 colours / shades can be quite tricky to get perfect especially if looking at light/dark themes
3. The best mitigation and to ensure we are not only relying on colours would be to add another affordance to provide meaning (labels directly on top of the stacked bars, lines to point to the portion of the stack bars, adding texture)

Ultimately like everything in a11y there are more than one correct way to go about it but depends on how deep you want to go/can go into making this dashboard more accessible.

I do see why Axel fails to equate gray only == more accessible, because of the issues mentioned above, also while it is nice to keep things colourblind friendly, adding more/diverse affordances can make this more accessible to folks with multiple visual impairments, thus yielding greater benefits.

Also I do disagree with the assessment that the previous colour palette was more accessible (ref: https://github.com/conda-forge/conda-forge.github.io/issues/2243#issuecomment-2266260967) as these colours still do not have enough contrast against the background, nor against their adjacent colours. Neither does the text on the chips against the chips colours, and the addition of the colour bauble is a good step in the right direction to provide affordances other than colour. See for example both using a monochromacy filter where colours almost blend into each other making segments and text almost imperceptible (this correlates with the contrast between colour pairs), which is also present in the linked “Turbo” colourmap meant to be “more accessible” if you look at the continuous colour band there is barely any luminance variation except when comparing extremes (left, right) vs the middle colour but even the discrete colours next to each other do not have enough contrast when checked as colour pairs (so no, starker colours do not equate to more accessible colours, turbo is a drop in replacement from jet and inherits a number of its pitfalls, especially if taken out of the visualisation context and trying to translate to UI/UX) That was a lot, so I would be happy to provide more context or help

@SylvainCorlay added:

Shades of gray actually have varying levels of brightness, making them more easily distinguishable to those with color blindness than colors of similar brightness but different hues. (This is a bit oversimplifying but shows that it can be counter intuitive). We should look into better color schemes overall based on accessibility studies.

[h-vetinari]

@jaimergp: For context, what we were trying to move away from was this situation:

That looks like the main problem there was about how to display disengaged filters, less about the colours per se.

@trallard via @jaimergp: I do see why Axel fails to equate gray only == more accessible

I find this mode of communication peculiar. Please address me directly, don't copy third-party quotes about me from somewhere I cannot interact with. The content of the statement is also iffy, as I never claimed that greyscale is necessarily less accessible. My point was that the grey tones being used were very close together, and that I found no rationale for how they were chosen.

@SylvainCorlay: Shades of gray actually have varying levels of brightness, making them more easily distinguishable to those with color blindness than colors of similar brightness but different hues. (This is a bit oversimplifying but shows that it can be counter intuitive). We should look into better color schemes overall based on accessibility studies.

I'm sure there are other works on this, but Turbo did look at various (simulated) types of colour blindness, noting:

We tested Turbo using a color blindness simulator and found that for all conditions except Achromatopsia (total color blindness), the map remains distinguishable and smooth. In the case of Achromatopsia, the low and high ends are ambiguous. Since the condition affects 1 in 30,000 individuals (or 0.00003%), Turbo should be usable by 99.997% of the population.

That low-end-vs-high-end ambiguity is IMO irrelevant here because we have a clear linear order for both the status bar and the legend, so (assuming their methodology and numbers are trustworthy) that'd put us in "accessible except for 1 in ≫30,000 users" territory.

This screenshot was taken at an unfortunate time (mea culpa), as two categories have 0 affected feedstocks and thus no colour bar to see how distinguishable they are (or not). Still, distinguishing the colours in the "bubbles" of the filters certainly seems like a challenging proposition IMO, which was my main point.

Your modification of my screenshots appears to model total color blindness. Are there even worse cases to consider or do we have a minimum "X" for "accessible except for 1 in X users"? Inversely, the migrator overview IMO remains usable even in the complete absence of a progressbar (thanks to the self-explanatory categories), which suggests that X < ∞ is workable, and we can find a balance between the various concerns, including the UX for the 99%+ case.