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 https://webaim.org/resources/contrastchecker/.

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 requirements.

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 flaws. 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 readability).

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.

Cheers,
Marvin
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to