Color blindness accessibility options for custom overlays

[Lumikeiju]

Use Case

I am unable to make use of the "Custom Overlay" functionality because I cannot distinguish between some of the colors of the circles.

For example, in the image above, I am able to pick out the #B861BE-colored circles in the top left, but the #FF0000-colored and #99931E-colored circles appear indistinguishable to me.

Proposed Solution

This could be solved by any of the following:

• Only using colorblind-distinguishable colors by default (an already established palette could be used, or a resource like this may be helpful for developing one)
• Allow for "hue-shifting" the overlay
• Providing the option to display a character on top of the circle to help distinguish the values.

[Helium314]

The custom overlay may produce similar colors in general. The coloring part would need to be re-written to somehow produce non-similar colors in all cases.

Providing the option to display a character on top of the circle to help distinguish the values.

Making anything depend on how many different values there are (be it the choice of color, or adding a number) is likely going to end up causing a lot of confusion, because only the currently displayed values can be taken into account.

[mnalis]

In other words, it is also possible that the people without color blindness will by chance get two colors which are visually very similar (like two very slightly different values of pink, for example).

The code currently makes a hash of the value being used as a key for a color, and then uses 6 hex-digits to create RGB color. That results in random color out of a pool of about 16 million different colors. Of course nobody can really tell the difference for 16 million colors... But the chance is that the values will be far apart that they would look different.

The advantage of that method is:

• the same value (e.g. house for coloring on building=*) will always have the same color, no matter how many possible values there are (which is important, because even if there are just say 3 different values/colors at this position on a map, if you scroll just a little there could could suddenly be 7 or 18 different values/colors; and you don't want colors changing randomly on every pan/zoom!) The disadvantage is:
• one gets colors at random, without any say in what they will be

---

Regarding proposed solutions:

Only using colorblind-distinguishable colors by default (an already established palette could be used, or a resource like this may be helpful for developing one)

It would seem to be hard to have any fixed list of colors while preserving the feature that one tag value always results in same color, which is very important.

E.g. it might be might be possible to create a list of 256 color-blind-friendly colors and use that short hash as an index to that palette, but with just 256 values collisions are somewhat likely (i.e. two different values might get the exactly the same color, which is quite unwanted!) Then again, it might work and collisions might be rare, hard to say. :man_shrugging:

Providing the option to display a character on top of the circle to help distinguish the values.

That one has too many problems IMHO:

• I don't even know how hard (if possible) it would be to add numbers in nodes
• there could be more values than 0 to 9, so circles would have to be big (or number small) to fit. And even if there are less then 10 values, we don't have a nice number from 0-9 (but instead of a number from 0-16777215) (because: see the advantage of current method mention before). One might try something like github autogenerated avatars instead of numbers, but that adds complexity and is harder to remember/spot...
• Custom overlays can color not just nodes, but ways and polygons too - where that "putting a number" solution wouldn't work at all (or at the very least would become hugely complex implementation effort)

Allow for "hue-shifting" the overlay

Now, this one might perhaps be possible. Do you @Lumikeiju (or anyone else) have ideas how that might work?

Given that the input number is random hex number from #000000 to #ffffff (currently corresponding to RGB color), is there a way where one can programmatically detect that the suggested color to be potentially problematic, and where one could mathematically convert that number to some other number, which would be guaranteed to be more colorblind-friendly (at least for few of more popular color-blindness variants)? If so, such solution might be significantly less collision-prone (and thus better) than "256-color palette" idea above.

[mnalis]

While some palettes can be found at https://davidmathlogic.com/colorblind/ or http://colorsafe.co/ (or more at e.g. https://ux.stackexchange.com/q/19592/56726); note that different types of color blindness affect different colors, so it is not easy to make a good palette if one needs more than a few colors. One could test various examples at https://www.color-blindness.com/coblis-color-blindness-simulator/

Also, general accessibility recommendations IIRC recommend never relying solely on color to convey information - that is unfortunate for such custom overlays -- SCEE colors not only nodes, but ways too, and there can be more than few values of those, so even if patterns could be implemented (dotted lines, dashed, dot-dash etc) the number of that combinations is too low to present all information.

---

I am wondering though -- at least recent Androids should include in its Accessibility Settings several options helping to deal with color blindness, e.g.:

Are you using that Android functinality @Lumikeiju , and does that help at all for SCEE Overlays? (or does it make things worse?)

[Lumikeiju]

Apologies for not responding earlier! I do think that avoiding relying on color alone is probably the best solution. I'll give that Android feature a try when I get the chance.

[Helium314]

I do think that avoiding relying on color alone is probably the best solution

This unfortunately completely goes against the way SC(EE) overlays are designed. Maybe show tags of the element for custom overlays (or only tags matching the color filter), but that can easily get ugly and confusing when there are many tags or elements.

[Lumikeiju]

Sorry, again, for the big delays in responses!

I was able to take some time this morning to mess around with the color correction settings in Android and yes, those help enough to enable me to differentiate the colors in this instance. As far as I know, I unfortunately can't set these settings to only enable on specific apps, but there's some options like putting the toggle in the navigation bar which make it easier to apply these settings when needed.

So, I'll close this as wontfix because the effort to implement a solution in-app is complicated (as discussed above) and there are existing, OS-level solutions. Thanks!