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.