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
___
