[Standards] Accessibility implications of XEP-0392 (Consistent Color Generation)

Marvin W xmpp at larma.de
Mon Oct 14 18:17:53 UTC 2019

Hi there,

Given the proposal to add 0392 to the CS2020, I thought it might be 
useful to have it analyzed for accessibility implications.
XEP-0392 is a bit special here, as it is not a technical specification 
of a wire protocol, but defines specific rules for user interface design.

In the §2 Requirements of XEP-0392, it already mentions the two main 
issues related to colors for accessibility: color vision deficiencies 
and contrast to background. §5.2 describes algorithms to correct for 
common kinds of color vision deficiencies. §5.3 describes an algorithm 
to adapt the color for the current background color. According to §6.2, 
the usage of §5.3 is optional if the background is not grayscale.

I'd like to point out several issues with the color generation in terms 
of contrast to the background color and especially with the specifics 
outlined in §5.3.

As described in §2, the generated colors should "decent" contrast on any 
background. Obviously it's hard to define what "decent" is, however 
others already invested time into that: W3C created the Web Content 
Accessibility Guidelines (WCAG, current version is 2.1). It defines 
three minimum contrast ratios that are of relevance here:
- Non-Text Contrast (Level AA): 3:1
- Minumum Text Contrast (Level AA): 4.5:1
- Enhanced Text Contrast (Level AAA): 7:1
Non-Text Contrast is relevant for automatically generated avatars 
(§3.3), Text Contrast for participant nickname coloring. You can 
determine contrast ratio using the tool at 

According to §5.4, the lightness parameter of HSLuv should be set to 
50%, independent of the background color. As HSLuv provides consistent 
color brightness, it also provides consistent contrast. At 50% 
lightness, the contrast ratio to a full white or full black background 
is consistent at about 4.5:1, so around the WCAG Minimum Text Contrast. 
That implies that the background must be either fully white or fully 
black, and then still it only suffices the level AA, not level AAA 

In practice I don't think it's feasible to reach decent contrast with 
one color for all backgrounds. That's why it makes a lot of sense to 
have something like §5.3, but it shouldn't be optional.

§5.3 describes an algorithm to adapt the color to the background. I 
assume this is to increase contrast, however it has several fundamental 
1. The algorithm is based on the RGB values. In §5 it is described that 
HSLuv is being used for its consistent brightness. However the §5.3 
adaption work on RGB, and so the consistent brightness is lost when §5.3 
adaption is applied. The contrast ratio to white thus is something 
between 6.35:1 and 6.55:1
2. The algorithm seems to assume that using the inversion of a color 
provides great contrast to this color, which is wrong.
Consequently the result of this algorithm neither provides consistent 
nor good contrast ratios. The inversion logic actually works against the 
contrast ratio: The contrast ratio to #282828 (Conversations dark theme 
background) is only 3.5:1 even when applying §5.3 (it is 3.28:1 without, 
so the improvement isn't that much.

I'd suggest to change XEP-0392 such that
a) Adjustment to background color SHOULD be done, if possible and text 
SHOULD NOT be colored at all if it's not
b) Adjustment works by changing lightness to a different value than 50% 
such that a specific contrast ratio is reached (or lightness is either 
0% or 100%, depending on background)
c) The target contrast ratio for both avatar and colored nick name 
should be defined in the XEP and may be different for the both (such 
that avatars might be darker/lighter than text, if that increases 

I put up this small demo to showcase a possible implementation of both 
use cases described in XEP-0392 here: https://larma.de/392.html (it 
doesn't include §5.2 corrections, but they only affect the possible hue 
values, so that's not really important for contrast). I did not have 
time to make the demo include my suggested changes, but people asked me 
to bring this mail faster so it is included in decisions around CS2020.

tl;dr: I don't think XEP-0392 is ready for being included in CS2020 yet, 
it can still be in future development section and I am happy to 
contribute to make XEP-0392 more ready for CS2021

As a side note: I think XEP-0392 should not be in Standards Track, but 
is better suited to be a Informational XEP, according to the definitions 
laid out in XEP-0001.


More information about the Standards mailing list