Can they turn off HTML emails?

It's also helpful to know which specific type of color blindness we're looking at here. We have lots of color blind users, but this is the first I've heard issue with diffs.

I'm not sure I understand what you mean. To be clear, the user doesn't have an issue reading the text; they have an issue distinguishing between red highlight and green highlight. I think it would be even more confusing without any highlighting at all.

The colorblindness is red-green, as noted above. I don't think there's a more specific subtype.

I went through color blindness simulators and I can distinguish every type using the supplied image. So without more information, I'm not sure how to proceed here. Why can't you ask them what type of color blindness they have, specifically?

There are 4 types of red-green color blindness, and they all work differently.

They don't know what type they have more specifically than red-green, unfortunately.

Uh, I'll see if they can take an online test to narrow it down further.

Of the four, this is the only type that's difficult:

http://www.color-blindness.com/deuteranopia-red-green-color-blindness/

Okay, after some tests, looks like the user has deuteranopia. Consistent with what you have there.

What color scheme would the user prefer?

Ideally, what are the hex codes of two specific colors which would work well for them as highlight colors for removed and added text?

If we added an option to Settings → Display Preferences → Accessibility to provide a specific affordance, what label would they expect? For example, would "Use Colors for Red/Green Colorblindness (Deuteranopia)" be an appropriate label that they could use to identify the option that would help them, or would another label be better or more helpful?

(See some vaguely related prior discussion in T3127.)

Slack has some nice color blind themes, which I use as my normal theme.

I wonder we could solve this with math since most colors are stored as hex (we'd have to move diff colors to hex, but that's not a huge deal).

My thoughts are all of these color shifts boil down to loss of certain spectrums. We could use values like http://web.archive.org/web/20081014161121/http://www.colorjack.com/labs/colormatrix/ which let's use see what these look like to end users, then reverse build a set of specific filters that deal with individual types of color blindness. Maybe this is also just overkill.

I'm hesitant about using math to solve this because I think Blizzard did that in Overwatch (apparently? or something?) and ended up with modes that were worse for colorblind users than users with normal vision:

https://www.reddit.com/r/Overwatch/comments/4lfit6/blizzard_the_deuteranopia_colorblind_mode_is/
https://www.reddit.com/r/Overwatch/comments/5i1z17/colorblind_mode_is_still_really_bad/

Perhaps they just did a really bad job of it, of course, but most of the comments in those threads from colorblind users seem to be praising systems that are more tailored/customizable rather than systems that do color correction math well.

In the case of inline diffs particularly, red and green also have semantic meanings. Even if we successfully math them into "dark grey" and "green-red" or whatever, we might end up with two colors that are distinguishable to colorblind users but do not have very strong "removed" and "added" connotations, so if only one was present it wouldn't necessarily be obvious if the text was added or removed. Other colors might be equally distinguishable and also more immediately identifiable as "removed" and "added".

I think there's no strict reverse transform for deuteranopia, since the function for it is destructive (both "red" and "green" map to "grey", sort of). Other vision conditions might be more amenable to using math to color-correct, maybe?

Yeah I'm wondering if a quick patch for this is just add + and - to the prose diffs.

That's easy to add, but I'd worry it will result in much worse readability for all users for diffs with a lot of small corrections. If there are just 1-2 big edits the extra "+" and "-" probably aren't a big deal, but choppier edits will get a lot of extra annotation.

wdiff does this in pure text mode, but I find it extremely hard to scan compared to the version with color:

I think I can get by just tweaking the red/green current diff colors.

If a change only had one of those colors (e.g., just one added section, or just one removed section) I think I'd have no clue if it was removed-red or added-red.

I think I'd learn, if that's the way I always saw red/green.

Do you specifically not want to add a red-green colorblind mode to the existing "Accessibility" settings?

I'm working with a color blind designer in another chat channel, they're looking over my work. We don't think it's needed.

Ah, cool. I'm 100% onboard with it if an actual affected user has confirmed that the change is good, I'm just really uneasy about accessibility changes that don't actually involve the affected users.

He said simulators don't work well... but I'm like (how would you know................)

Haha, maybe it's like when Blizzard uses a simulator to build a colorblind mode they screw it up, therefor the simulator must not work?

I really want a small remarkup block sometimes.

Thanks for the quick response! I'll send that last image over to our user, and see if it's an improvement for them as well.

They said it's a definite improvement. Nice!

At least one user over email (and I think @epriestley also) mentioned the light highlighting of full lines is hard to distinguish / understand as full change in diffs. I'll look more into these issues before next release is cut.

T12089 has a narrower description with some screenshots, I think the behavior got flipped by accident.

See some additional discussion in T12172. Briefly:

• Colors are now used consistently in all web and mail diffs across all settings and modes.
• We've moved "Deuteranopia" mode to Settings → Display Preferences → Accessibility because the new colors were a little worse for users with normal vision and also worse for at least one user with protanomaly, in T12172. The default colors have returned to their old values.
• Because this is now a separate mode, we could freely select more extreme colors if users with with deuteranopia would prefer that. Likewise, we could now add other colorblind modes for users with other forms of colorblindness. (Installs can also provide new modes locally by writing about 10 lines of extension code.)
• Future work in T5701 will allow users to change the color scheme used by syntax highlighting.
• Future work in T12311 will allow users to select both "Larger Fonts" and a color-correction mode ("High Contrast", "Deuteranopia", etc). These option are currently mutually exclusive for purely technical reasons.