osmcha-frontend icon indicating copy to clipboard operation
osmcha-frontend copied to clipboard

Current colouring schema is not colourblind friendly

Open Andygol opened this issue 7 months ago • 7 comments

The colours in the OSMCha logo were originally chosen to be friendly to people with certain colour perception impairments. Now, after the changes have been made, it is quite difficult to visually assess how the map elements have been changed. It would be good to stick to the original colour scheme when displaying changes in the map view. 🙏

Andygol avatar Apr 26 '25 13:04 Andygol

In general, there is no difference between added features and features whose geometry has been changed

Deuteranopia Normal vision
Image Image

https://en.wikipedia.org/wiki/Color_blindness

Andygol avatar Apr 26 '25 13:04 Andygol

Thank you for this feedback. I will do some testing using the colorblindness simulation filters in Firefox's devtools and adjust the map feature colors to be more accessible.

jake-low avatar Apr 28 '25 21:04 jake-low

@jake-low thank you in advance for the update. In my turn I may offer to use app Sim Daltonism or tools to pickup and test colours on coolors.co or similar services.

image

Andygol avatar Apr 29 '25 06:04 Andygol

I've been testing and tinkering with the color scheme of the OSMCha map visualization. I haven't found a good solution yet, but wanted to document my findings so far here.

Here is the color scheme previously used by the map visualization of OSMCha (and still used in changeset-map which until recently was a dependency of OSMCha).

Image

In order from left to right:

  • background color (a representative sample of the default dark satellite imagery background); all of the other colors need to have good contrast against this background
  • created elements (turquoise)
  • old versions of modified elements (brownish-orange)
  • new versions of modified elements (yellow-gold)
  • deleted elements (red)
  • changeset bounding box (violet)

Recently (as part of #772), the OSMCha map visualization's color scheme was changed to the following:

Image

In order from left to right:

  • background color (representative sample)
  • created elements (turquoise; very similar to before)
  • old versions of modified elements (middle gray)
  • new versions of modified elements that have tag changes (yellow-gold)
  • new versions of modified elements without tag changes (light gray)
  • deleted elements (red; lighter than before)
  • "context" elements - members of modified relations, and parent relations of modified elements (violet; darker than before)

These color scheme changes were made in order to support some new functionality, specifically:

  1. Distinguishing modifications to elements' tags from modifications that only affected an element's geometry, since the former is usually more interesting to reviewers
  2. Showing contextual elements (relation members and parent relations) by default, rather than hiding them until the user clicks on an individual element. This is especially helpful when viewing geometry changes to multipolygons.

I tested the new color scheme using coolors.co's color blindness simulations for the two most common types of color vision deficiency: protanopia and deuteranopia. Here are those results. (Note: these are simulations that approximate what a person with these conditions might experience, indented to be viewed by someone with full color vision).

Protanopia (coolors.co): Image

Deuteranopia (coolors.co): Image

To me (a person with full color vision), these simulations appear to indicate adequate differentiation between all colors in the scheme under these forms of color vision deficiency. The colors for created elements and for context elements render similarly, which means that they could be more easily confused by someone with CVD, but the three primary colors (created, modified, deleted) appear easy to distinguish from each other, and from the gray values used for geometry-only changes.

However, using Firefox's devtools to simulate the same types of CVD produces different results:

Protanopia (Firefox): Image

Deuteranopia (Firefox): Image

In these simulations, the colors for created elements is quite similar to those for modified elements with geometry-only changes. In the Protanopia simulation in particular, these two colors are barely distinguishable.

Google Chrome has its own CVD simulations which yield results that are different yet again:

Protanopia (Google Chrome): Image

Deuteranopia (Google Chrome): Image

These results show significant color confusion problems, similar to Firefox, but in these simulations the issue appears to be worst for viewers with Deuteranopia, rather than Protanopia.

I tried adjusting the colors in OSMCha's color scheme to address the issues seen in all of the above simulations, but ran into problems with each approach that I tried.

  1. Hue-rotation: the turquoise green used for created elements can be confused with gray according to this chart. Rotating the hue can alleviate this. However:
    • making this color more yellow makes it too easy to confuse with the yellow-gold used for modified elements
    • making it more blue makes it too easy to confuse with the violet used for context elements
  2. Value separation: the turquoise green and the light gray have similar value (lightness); making one darker and the other brigher can make them easier to distinguish. However:
    • making the turquoise darker lowers its contrast against the dark background
    • making the gray brighter makes its contrast too high (drawing more attention to these elements and less attention to the other colors, when semantically that is the opposite of the intent)
    • making the turquoise bright and the gray darker is also an option, but this requires dramatically brightening the turquoise and dramatically darkening the gray, which results in gray values that are hard to see against the background (especially for old versions of modified elements which should be darker / lower contrast than new versions). It also makes the turquoise appear washed out and too easy to confuse with white or yellow-gold.

I will keep experimenting with this when I have some more time to work on it. In the mean time, if you use OSMCha and have any form of color vision deficiency, I would like to hear your feedback on the color scheme. Please feel free to comment here.

jake-low avatar May 01 '25 19:05 jake-low

If you want another data point for testing, Android's dev menu also has different color deficiency settings.

mxxcon avatar May 04 '25 15:05 mxxcon

Hi I'm new to OSMCha-- can I ask what each color represents? I've been trying to figure out how many buildings I've digitized @Andygol @jake-low

clo3potpot avatar Jun 06 '25 14:06 clo3potpot

Sure @clo3potpot, here's a quick guide.

  • turquoise green indicates elements that were created in the changeset
  • red indicates elements that were deleted in the changeset
  • yellow indicates elements whose tags were modified in the changeset
  • gray indicates elements whose shapes were modified in the changeset. dark gray is used for the old shape and lighter gray for the new shape. If an element's tags and shape were both changed, yellow is used for the new shape (see above).
  • purple indicates elements that were not changed but are being included on the map for context. This includes parent relations of ways that were modified, and children of relations that were modified.

There are also two different line styles used for ways:

  • dashed lines indicate the old version of elements, from before the changeset
  • solid lines indicate new versions of elements, after the changeset

So a way that was created will be shown with a solid turquoise green line, a way that was deleted will be shown as a dashed red line. If a way's shape was modified, the old shape will be shown as a dashed dark gray line, and the new shape will be shown in either solid yellow or solid light gray, depending on whether its tags were also changed.

It's on my TODO list to add this information in a "legend" panel in the OSMCha UI (edit: opened an issue to track this, see #809), but I hope this helps in the mean time.

jake-low avatar Jun 06 '25 21:06 jake-low