[Standards] XEP-0392: colour vision deficiency adaptation

Jonas Schäfer jonas at wielicki.name
Wed Oct 13 15:23:47 UTC 2021


Hi everyone,

XEP-0392 (Consistent Color Generation) includes suggestions for adapting the 
output based on vision deficiencies of the user.

While this may improve accessibility, the question has been raised whether 
that even makes sense to handle at this layer.

1. Effectively, CVD-corrections reduce the colour space. The CVD itself does 
that, too. If the CVD and the correction do not exactly align, the impact may 
be an unnecessary further reduction of distinguishable colours. If they do 
align exactly, there is no gain from the CVD correction.

   Example: suppose a user is completely unable to distinguish green shades 
from red shades (so there's 120° of the hue space which is redundant). If the 
CVD correction folds half of the colour space (180°) onto the other half (as 
the current correction does), 180° (half) of the colours are eliminated for a 
CVD which only affects 120° (one third). That sounds suboptimal.

   Am I misunderstanding this? Does anyone have more insight?

   If the CVDs had instead a measure to influence a collision avoidance for 
colours close to one another in the same or different shades, it would be a 
different story -- but such a mechanism (deliberately!) does not exist in 
'392, so it makes no sense.

2. Operating systems might (and especially mobile OSes do) already provide 
accessibility tools which perform folding of the colours, probably in more 
advanced/useful/correct ways than this code could (without exceeding 
complexity). 


Based on these two observations, I would suggest to drop the CVD correction 
sections from the XEP (while maybe retaining a note in the accessibility 
considerations, that toolkit- or OS-wide means should be used) completely. 
This would simplify the logic and document altogether significantly.

Unless there are objections within the next few weeks, I'm going to do just 
that and then ask the Editor to issue a Last Call for the document, given that 
it has seen a lot of deployment now.


kind regards,
Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20211013/a775f509/attachment.sig>


More information about the Standards mailing list