E-mail List Archives
Thread: 1.4.1 use of color for state indicator
Number of posts in this thread: 21 (In chronological order)
From: glen walker
Date: Mon, Mar 09 2020 12:20AM
Subject: 1.4.1 use of color for state indicator
No previous message | Next message →
--00000000000068f3f105a0660246
Content-Type: text/plain; charset="UTF-8"
[image: image.png]
(Image Description: Four buttons, labeled A, B, C, and D. Buttons A, B,
and D have black text and a white background. Button C has white text and
a black background.)
If you have a set of buttons, such as in a toolbar, and one button is
selected and the others are not, and that selection is indicated by a color
difference, isn't that a 1.4.1 failure?
"Color is not used as the only visual means of conveying information..."
The example in the image has the highest contrast difference between states
but there isn't a requirement for contrast between states. Technically,
the black selected button is only different from the other buttons by
color. It's using color as the only means to convey the selected meaning.
Even if the selected button had a "pushed in" appearance, that would still
only be a color difference (having the southeast button borders be a light
color and the northwest borders be a darker color).
F73 (https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/F73) talks about
red and pink not being color differences but rather lightness differences
so if my unselected buttons were red and the selected button was pink, it
could technically pass, but I'm sure I agree with that.
F73 could be applied to the black and white buttons too, and as noted in
"Note 1", the buttons would differ by both color and lightness so could
technically pass.
This just seems weird. White is a color and black is a color and that's
the only difference between the buttons and that difference has meaning, so
it seems like it would fail.
I know the buttons could pass if the selected button had a bold or italic
font, such this:
[image: image.png]
(the bold font of the C button is hard to distinguish)
[image: image.png]
(italic font is a little easier to spot but still not great)
Or if there was some other visual indicator to show its selection, such as
an extra underline under the button such as this:
[image: image.png]
I can't think of a case where a user that has sight, even if severe color
deficiencies, could not tell the difference between the buttons without the
font change or underline. (Assuming aria-pressed is specified too).
--00000000000068f3f105a0660246
Content-Type: image/png; name="image.png"
Content-Disposition: inline; filename="image.png"
Content-Transfer-Encoding: base64
Content-ID: <ii_k7k1xqb11>
X-Attachment-Id: ii_k7k1xqb11
iVBORw0KGgoAAAANSUhEUgAAAKcAAAAiCAYAAAA6a8mHAAAEEklEQVR4nO2cT0gjVxzHf7dBpEgC
OUn2EkoPHqTUg2xOWcoeLMQVukihORVbPHgpLAUpBAqhROhCaSA5NL3k4GULCbs9VNbiwoKGtf9g
uy4NYWkCEihYISJKDp8ekrhqJ6kzvsm8gfeBd0nC8+tvPs7vvTdBwWDQFPE7gMEwCCOnQVuMnAZt
uSBns9nUZtRqNdvAfucKWsZisah9xkH11FLOWq1GPp/XuqhByFgsFrXPOKyetnL6TT6f/9+i+s1V
MoqIryMIdexjl9XI6RIjp1qMnAoxcqrFyKkQI6dajJwKMXKqxXM5n2enu4UJLbNx4noaD4paJmV3
AccjTN3JstV0HtY7OcPMZSr82jjkuNOdr3N8SKtepZKZI+yznGfX+NywJiaZuvUxucevOHI8YxeP
5dwlHesHDrF8DTs9kzP2LktLS73xAbfenMASQSIrbDqM64mcY2/z1bN/6ACctmm8qFKtVvmt/veZ
qL98qYOcId55/1wdpyKM935m5HaB311cem/l3E0TEyGeyZAUIbS8gVs9PZMzVb70eotS0kIkyuq2
+ozO5Bzj7qN9ANq1dT4MX3o/fJPPKjWeaCHnNNnnF18/aW6RvR3pCpoq03I4r6dy7qZjiMTJ1Q8o
JQWxUpRd2jk6OWF7NYrIDPdfqs/oSM4b3/BHB2g/5d6YvmvOQXL23uX+jIVIjPSus3k9lLPX0uM5
6kCjkEDEIuXSztHIecSrxxkSISHy0Q8ceJDRiUg38nsA7FfmlYjpj5xwsrFMSISow1bknZy9lj7d
T9wokBDBSpVdtfaRbYhEeOO9AnsuVvGq5Zyv7AMdnn2hRky/5OSgRFIESRRoOJjXMzm7Lf184AaF
hPvWPpoN0RLJ2d5CPpKi7HCRpFrOz3dOgX0q8wGXs1/r6SwDP2KDR3Jusxr9b5jrtPZRrjlbDxYJ
ifMNnLlzDvhA/86ZLDlaKnkj5/Yq0SEFshbWPVnPOWOwnCr/0i9nNGvOq+OJnN3d7vlzr9fnX7MR
QawF1h3aOVI5Tx6wqIGcMlOiDgHfrfeP5rTYrfdaeiyNXZbuL2Kx4NDO0cl5xM+ZGSwRYg6r6cU5
572nbWDYOedLfnLQ9kcq59Ee3y1OYom604/rybm5QmjYha3niLto7aPZECWZjYx3lx5vfcqmB3d3
x3e7sbt8/9dpd5JAPiGymFws8acOT4g2V0LDF8fUycWdt/bRHCVZTExOcSf9UIujpNcjzNzXT6i3
2vQ0pXN8SOPFj3z7yU29n61vNZU+FTTfSnKJ+VaSWoycCjFyqsXIqRAjp1qMnAoxcqrlSnLu7Oyc
fdDvYUdQMq6trfmeLUh1tMt6QU7dwtoRhIw6iRmUOtplNf+OxqAtRk6Dthg5Ddpi5DRoy7/zk+cz
eg5b1wAAAABJRU5ErkJggg==
--00000000000068f3f105a0660246
Content-Type: image/png; name="image.png"
Content-Disposition: inline; filename="image.png"
Content-Transfer-Encoding: base64
Content-ID: <ii_k7k2jhhy2>
X-Attachment-Id: ii_k7k2jhhy2
iVBORw0KGgoAAAANSUhEUgAAAKoAAAAhCAYAAABJATCZAAAEQUlEQVR4nO2cP2hbVxSHz/YwohgZ
NCVuB1E0ZBAhHoRNB5dMLchxKIRANAQjiqFaCl00VFAQRR5CQw3yEE8eTCAFmTaDjQUpCcglbqHU
jQNCFEshiA5KwSY4ZPg6SLFl5cn2ld59f+D+4A7Se7rvp/O+d8899woJRkYBkHhtwMjoPDKgGgVC
BlSjQMgW1Eaj4ZtWrVZtjXvtK2geG40Gy8vLfUHw2ttZMfU1qNVqlWKx6OvABsFjo9GGtJ9Pv3m1
i+mpoHqtYrF4JgRe6zweRcTzdprPbq9+kJ1XA+qQMqA6LwOqBhlQnZcBVYMMqM7LgKpBBlTn5Rqo
O4V4O0DheTYOB+5GA6glUnY3MhTh0rUCjxrqZnWCOvbZXdaf1fnv9dujPt/st6g/W+fel5OMeQ1q
KWUby48SSb69/xetAe+9S6Buk4u+Mx5mfghStYEavUo6ne60m3z68SiWCBLJUFa0qwfUMW6t7fHm
jGv/8b0/QI1eTR/FM5m4wKjVvqYVy7DRVOsS3AJ1O0dUhKl8nqQI4fkNBkVVG6ipUs/7TVaSFiLj
ZCvOe1QFNVbcpWsMZe/XPNcvjiAywsXredar+4B/QH0vnAe73J+LYYlgTRT404GH33FQt3NRRKZY
rLVYSQpipSg5mAKG89gPVKhkxxGZ4M5z5z0qgTqSpfL6uI/9J98w8t55Mb7afMFTv4IKQIuHcxFE
LGZXW0rdugBqJ+1PLVID6kvTiFikBiTVHVAP+Gczz3RYiMw9RC2kGkD97mnXaLrH6ieDzW+9BxWo
LTIlgiRXlOKqH9RO2o8Xdtqv60tMi2ClSgOlf9eKKRE++HyJ3QM9HlWAmll7edzBq03SDkDqGahU
yI4LEs5QVuhWO6jttB/nHadQZ2l68PTvTjGVJpmIEBJBIilKipN/raC+XGMm0KDuUIgLIin6nmIj
zaB2np54gZ2ud4dJ/27OUZsPbhAW9eLPjKjnGFHHs6jUqHpBrWQZPyVQ1uyqlvmfmvqDenSs50Fz
wqOZo/pojtqumsNc+SJ9Iq2m0zdJRASxZlEs/twF9fABN/wA6oc/8vcxqX2q/jFu/eL3qv+QSjaK
z6r+zhAfzbFtc7S9U+WM4cE9Qn9QD/g9P4ElQjRn9w2G86g6+s389OLEOmpz6+7JddTnr3iLj9dR
Dxs8yk0SEsGauKP04INOUMsZwqfd5E4KUE3/7hRTSRKRUHt6EvuasoZRXz1Vx8g++bcLVnv5BdR+
O1OhyRyP/bQzVc6EOVnt96rG4pR6+ndnecpi9MIlruV+9sXy1HEb4fLtezZ7/U1qv63xw+3LNlMC
b0A90Y72+ncZIJyA+fWUFplfTzkvA6oGGVCdlwFVgwyozsuAqkEGVOelBOrW1tbRB7xuQfa4sLDg
ubezfPoxnr1ebUH1s+EgefQbpP18+jGevV7NX/oYBUIGVKNAyIBqFAj9D6VC3SqcAoDOAAAAAElF
TkSuQmCC
--00000000000068f3f105a0660246
Content-Type: image/png; name="image.png"
Content-Disposition: inline; filename="image.png"
Content-Transfer-Encoding: base64
Content-ID: <ii_k7k2l03a3>
X-Attachment-Id: ii_k7k2l03a3
iVBORw0KGgoAAAANSUhEUgAAAKgAAAAgCAYAAACGqDMBAAAERklEQVR4nO2cP2gbZxiH3+0QphgF
NDnqIooHD8bUg6nIoFAytKDEocV00FRcMNRDCqEgCoKAMPIQCBikoWoHDVoyyLQdbGzw4CKLuq5T
gl0q1FAJgtqAE5ARDhqeDie5siPJudP9E3wP3CKJzz+/9/je74+woFB4GHE7gEIxiAuC1mo1z1zl
crlnYLdzjVrGbDbr+YyD6ulJQcvlMul02tOFHYWM2WzW8xmvqmdPQd0mnU5fWVi3eZuMIuLqNQp1
7NAvqxLUJEpQa1GCWowS1FqUoBajBLUWJajFKEGtxRFBn6am9eL4l9g8Mz2MDYUtEOt1E8cCTN1J
sVMzHtYZQa/xwdd5SpU6jdftwVtNXlWP2Hh0l+s+5wU9v8ddlzY+wdTNL1jbesap4RF1HBB0n0So
E9rP0hCG2iZo6EMWFxfb12fcfG8cTQQJLLNtMK7tgk5+yXq5AUCr+YLKYYlSqcRRtYHu6ku2Ft0S
1M/7n3TVcSrAWPtnBm5leGLi1tsv6H6CkAjhZJKoCP6lTcwqapugscKl1+vkohoiQeJF6zOalzPO
7r8taL3k928/4tql930z99j462ceuNDidUGnST29+PpZbYfUrYAuaaxA3eC4tgu6nwghEmatckIu
KogWo2DSUOcEhWI8iMgsD/+wPqM5QSdZOWgADQ5WJj03B+0naPtdHs5qiIRI7Bsb12ZB2+09vEYF
qGYiiGjETBrqjKCnPNtKEvELgc9/4sSGjGak8t3fpQE0du/jG3IO67ygcLa5hF+EoMGWZK+g7fY+
3UldzRARQYsVTLV5xxZJIrzzcYZjEzN7ewT1sXLQAv4mf2M4Od0SlJMcUREkkqFqYFxbBdXbe3fo
KpmI+TbvzCJpkehce3IfiFEwOGmyR9AH/NICnq9ze0g5XRO0U+vpFH0/0gMbBS0SD74ZaJg27+Qc
tP54Ab8YX9TZIujtdZ4DHKwMLafrT9BoztC0yT5Bi3GCA4qkzedtmd8Zo7+gVv/Fd2c0LNXKgT7A
CAvquTmovgru3hf7f39sLiCINk/eoKGOCnr2mAWvCPrpj/wDI9ziO9t2nlnFt9t7KEGvPPovozFv
0FDnBD3l1+QsmgghgxW1RVBfnGIToMmTRzOXVvE+rt9NsnG0wTdeFPT0mO8WJtDE2l2R4QTdXsY/
6OZW1gibaPPOLJKizAXG9GnI5Fds2/CUN/PUu/F9uX1S1KL5osJhqUTpsEK9c9Z5nOZd1wXtd5Kk
MbGQ40+vnCRtL/sHT5ipsBY23uad2WbSGJ+Y4k7iBw9tM+lPypl7eX6rvqLZag/4ukG9UmI9efX5
uzOCXvw552fxOzXLTw/Vt5lMor7NZC1KUItRglqLEtRilKDWogS1GCWotby1oHt7e+cfdvvqxahk
XF1ddT3bKNWxX9YLgnotcC9GIaOX5ByVOvbLqv71jcLTKEEVnkYJqvA0SlCFp/kPOUE0jA5+QpQA
AAAASUVORK5CYII=
--00000000000068f3f105a0660246
Content-Type: image/png; name="image.png"
Content-Disposition: inline; filename="image.png"
Content-Transfer-Encoding: base64
Content-ID: <ii_k7k2n5zx4>
X-Attachment-Id: ii_k7k2n5zx4
iVBORw0KGgoAAAANSUhEUgAAAKgAAAArCAYAAADsb8PCAAAFy0lEQVR4nO2cT0gjVxzH320QKUuE
nIp7CWUPe5BSD7KeLHuphewKXZaF5lRC8eClIAUpCIVQFFooFeKhOXnwsgVDW2PUlEzYoEk0bSTZ
XRykNor4j6kxmphM9NtDMlbdJDrjvPmD7wO/i8E3P37zmfd7700IAYNhYojRCTAYzWCCMkwNE5Rh
at4RdGNjwzQhCELdpI3Oy2o5+nw+0+fYqI6mFVQQBHi9XlMX1go5+nw+0+fYrI4NBTUar9d7bWGN
5iY5EkIMDavXkQl6C5ig2sAEpQQTVBuYoJRggmoDE5QSTFBt0FXQ9EhHtTi2fsyeqB6GQmGn4Kp3
E1vtePh0BOEN5cnSE7QNvR4//sweoCBVx5MKB9hei8Hv6UWbaQQ9wZSLq16rewxrKkfRUdAlDDvk
4tjQfwtDqQnqeAy3212LF/j4g3vgCAGxDyCkMF0qgrZ8iO8T/0ICgFIe2dcxxGIx/LW2dy5r8juT
CCpOoo+Tr9WNMZWG6ifo0jAchKDb44GTENj6Z6FWUWqCuqau/H0bE04OhLRjaEH7HJUJ2oJnv20B
APLCJD5vu/J52yN87RfAm0RQcbIPHLGh3zOIdkLQrdJQ3QRdGnbUniQRE04CwrkwpdJQ/QQFFoba
QUgnfnirfY6KBL3/EzISgPwrDLaYfQ0qYrKPqy3lFjDUTkA6RpBWMZJOgtbae20tkh3vASEcXCoN
1UfQI/w970GPjcD+xe8QKeSoRKb73jcAgC3/E03kpCporb3LXTI0YAMhHRhRYag+gtbae4ecYXYc
PYSAc02pavO6bZIIwXufjuPNEZ0clcj0xL8FQELiW23kpClotb1fmIBCA7BdvP8K0EXQanu/+ARl
Md6jvs3rs0lyw9llRyshIHYXpra1z1GJTN8slgBswf/E7ILW2vulexvCgE1dm9dB0PprkNu0eT3X
oNsvn8NGlG/q7uwMKk7AWac7qm3z9AVdGEJ7kyJxfZNU1nfKaCzo+WcKn/67ugYVJ5xNr+kYXlI0
HnVBq7tgGz76zH2pfbrdL9BlJyBcHyYVGqqroCcv8dwEgpLOiepht6l38bUTGuLAY/fV+/0JHnAE
xDEMJYpSFrTW3hskVX2zxKFPoaH6CXqEZU8nOI2ffLXnoIOv8gCanYO+xR8KlgCa11Fu73W7ovxm
yQElpaQraG331vDmro2hW0Wb12eT5ESXvbW6DHnwFUIUZnnFs17LM/zyT6k6iAnfJMn7ikYTzsls
f3Mf6kBV0OsXxmsY61be5vU5ZuJw7/2HeDr8qymOmf6PNvT+yGNtO4+aqpAKB8i+DuLnLx8Z+C7+
BiczJ7Potylr8+zbTJRg32bSBiYoJZig2sAEpQQTVBuYoJRggmqDYkEXFxfP/8noqIdVchwdHTU8
N6vX8R1BzZRwo6StkKOZ5LRyHdlP3zBMDROUYWqYoBQ5OzurG6enp9Sj3nWtCBOUAvVkrFQq5yFJ
EvW4eL2rwloJJqjGyFLKIhp9zCSHLK0sq1VggmrIRTlLpRIKhYLhYspRLBZRLpdRqVQsNZMyQTXk
7OwMlUoF5XIZhUIBuVzOcDHlyOVyKBQKKJVKlppFmaAaIc9KkiShWCwil8thd3fXcDHl2N3dxeHh
IYrFIiRJwunpqdEluxFMUI2Q23u5XMbx8TFEUcTm5iYEQUAqlUIsFkM0GgXP8wiHw1SD53lEo1HE
YjGkUimsrq5ic3MToiji6OiICXoXkQUtlUrI5/PY29vD+vo6MpkMEokEIpEIQqEQgsEgZmZmEAgE
qEUwGEQoFALP80gkEshkMlhfX8f+/j7y+fyltajZYYJqRDNB4/E4eJ7H/Pw8AoEApqenqcbMzAzm
5uYQDocRj8eRTqeZoHed61p8PB5HNBpFJBKh2uZ5nkckEjlv8SsrK5da/PHxMWvxd5F6m6SdnR1k
s1msrq4inU4jlUohmUxieXmZaiSTSaRSKaTTaQiCgGw2a9lN0n+fGfttJN9nGAAAAABJRU5ErkJg
gg==
--00000000000068f3f105a0660246--
From: Steve Green
Date: Mon, Mar 09 2020 1:34AM
Subject: Re: 1.4.1 use of color for state indicator
← Previous message | Next message →
I expect that the rationale is that people need to be able to differentiate between the states if they have overridden the stylesheet. What do those links look like when using the operating system's high contrast mode?
Steve Green
Managing Director
Test Partners Ltd
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: 09 March 2020 06:21
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] 1.4.1 use of color for state indicator
[image: image.png]
(Image Description: Four buttons, labeled A, B, C, and D. Buttons A, B, and D have black text and a white background. Button C has white text and a black background.)
If you have a set of buttons, such as in a toolbar, and one button is selected and the others are not, and that selection is indicated by a color difference, isn't that a 1.4.1 failure?
"Color is not used as the only visual means of conveying information..."
The example in the image has the highest contrast difference between states but there isn't a requirement for contrast between states. Technically, the black selected button is only different from the other buttons by color. It's using color as the only means to convey the selected meaning.
Even if the selected button had a "pushed in" appearance, that would still only be a color difference (having the southeast button borders be a light color and the northwest borders be a darker color).
F73 (https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/F73) talks about red and pink not being color differences but rather lightness differences so if my unselected buttons were red and the selected button was pink, it could technically pass, but I'm sure I agree with that.
F73 could be applied to the black and white buttons too, and as noted in "Note 1", the buttons would differ by both color and lightness so could technically pass.
This just seems weird. White is a color and black is a color and that's the only difference between the buttons and that difference has meaning, so it seems like it would fail.
I know the buttons could pass if the selected button had a bold or italic font, such this:
[image: image.png]
(the bold font of the C button is hard to distinguish)
[image: image.png]
(italic font is a little easier to spot but still not great)
Or if there was some other visual indicator to show its selection, such as an extra underline under the button such as this:
[image: image.png]
I can't think of a case where a user that has sight, even if severe color deficiencies, could not tell the difference between the buttons without the font change or underline. (Assuming aria-pressed is specified too).
From: Patrick H. Lauke
Date: Mon, Mar 09 2020 2:54AM
Subject: Re: 1.4.1 use of color for state indicator
← Previous message | Next message →
On 09/03/2020 06:20, glen walker wrote:
> [image: image.png]
> (Image Description: Four buttons, labeled A, B, C, and D. Buttons A, B,
> and D have black text and a white background. Button C has white text and
> a black background.)
>
> If you have a set of buttons, such as in a toolbar, and one button is
> selected and the others are not, and that selection is indicated by a color
> difference, isn't that a 1.4.1 failure?
For what it's worth, in our evaluations we've treated a reversal in
foreground/background as a valid indicator, as it's a drastic change in
lightness (adapting the rationale of that particular note in F73). So
even the very first example would be a pass in my book.
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Murphy, Sean
Date: Mon, Mar 09 2020 2:57AM
Subject: Re: 1.4.1 use of color for state indicator
← Previous message | Next message →
If you are using a button. Does the buttons have text? If so, then you could indicate bold for the selected button. Making the border of the button thicker compared to the other buttons could be another options. Using a graphic to indicate the selected button. The graphic could be an underline. Just ideas.
Sean
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Steve Green
Sent: Monday, 9 March 2020 6:35 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] 1.4.1 use of color for state indicator
[External Email] This email was sent from outside the organisation â be cautious, particularly with links and attachments.
I expect that the rationale is that people need to be able to differentiate between the states if they have overridden the stylesheet. What do those links look like when using the operating system's high contrast mode?
Steve Green
Managing Director
Test Partners Ltd
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: 09 March 2020 06:21
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] 1.4.1 use of color for state indicator
[image: image.png]
(Image Description: Four buttons, labeled A, B, C, and D. Buttons A, B, and D have black text and a white background. Button C has white text and a black background.)
If you have a set of buttons, such as in a toolbar, and one button is selected and the others are not, and that selection is indicated by a color difference, isn't that a 1.4.1 failure?
"Color is not used as the only visual means of conveying information..."
The example in the image has the highest contrast difference between states but there isn't a requirement for contrast between states. Technically, the black selected button is only different from the other buttons by color. It's using color as the only means to convey the selected meaning.
Even if the selected button had a "pushed in" appearance, that would still only be a color difference (having the southeast button borders be a light color and the northwest borders be a darker color).
F73 (https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/F73) talks about red and pink not being color differences but rather lightness differences so if my unselected buttons were red and the selected button was pink, it could technically pass, but I'm sure I agree with that.
F73 could be applied to the black and white buttons too, and as noted in "Note 1", the buttons would differ by both color and lightness so could technically pass.
This just seems weird. White is a color and black is a color and that's the only difference between the buttons and that difference has meaning, so it seems like it would fail.
I know the buttons could pass if the selected button had a bold or italic font, such this:
[image: image.png]
(the bold font of the C button is hard to distinguish)
[image: image.png]
(italic font is a little easier to spot but still not great)
Or if there was some other visual indicator to show its selection, such as an extra underline under the button such as this:
[image: image.png]
I can't think of a case where a user that has sight, even if severe color deficiencies, could not tell the difference between the buttons without the font change or underline. (Assuming aria-pressed is specified too).
From: Patrick H. Lauke
Date: Mon, Mar 09 2020 3:06AM
Subject: Re: 1.4.1 use of color for state indicator
← Previous message | Next message →
Additionally, I'd note that the SC 1,4,1 Use of Color is...a bit
problematic/internally inconsistent in its understanding document, in my
view...
https://github.com/w3c/wcag/issues/1076
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: glen walker
Date: Mon, Mar 09 2020 4:40AM
Subject: Re: 1.4.1 use of color for state indicator
← Previous message | Next message →
But from a strict reading of 1.4.1, it sounds like a failure. Color *is*
being used as the only indicator. Whether it's a dramatic change isn't
implied in the success criterion.
My example was intentionally extreme.
When would an example cross the border of being extreme, whether black and
white, or reversal of foreground and background colors, to something that's
still maybe ok to when it becomes not ok?
So if the buttons have a white background initially, and the selected
button has a blue background, is that a failure? If the blue is still dark
enough that it passes, when does it not pass? As the blue gets lighter?
As the contrast ratio approaches 4.5?
That seems a bit subjective. Color is still being used as the only means
to convey information. Or should 1.4.1 really be "if color is the only
means" *and* contrast is below a threshold, then it fails?
On Mon, Mar 9, 2020 at 3:06 AM Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:
> Additionally, I'd note that the SC 1,4,1 Use of Color is...a bit
> problematic/internally inconsistent in its understanding document, in my
> view...
>
> https://github.com/w3c/wcag/issues/1076
>
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >
From: Patrick H. Lauke
Date: Mon, Mar 09 2020 4:48AM
Subject: Re: 1.4.1 use of color for state indicator
← Previous message | Next message →
On 09/03/2020 10:40, glen walker wrote:
> But from a strict reading of 1.4.1, it sounds like a failure. Color *is*
> being used as the only indicator. Whether it's a dramatic change isn't
> implied in the success criterion.
>
> My example was intentionally extreme.
>
> When would an example cross the border of being extreme, whether black and
> white, or reversal of foreground and background colors, to something that's
> still maybe ok to when it becomes not ok?
>
> So if the buttons have a white background initially, and the selected
> button has a blue background, is that a failure? If the blue is still dark
> enough that it passes, when does it not pass? As the blue gets lighter?
> As the contrast ratio approaches 4.5?
>
> That seems a bit subjective. Color is still being used as the only means
> to convey information. Or should 1.4.1 really be "if color is the only
> means" *and* contrast is below a threshold, then it fails?
Well, that's the "joy" of those SCs (and that "by the backdoor"
redefinition of "color is hue, not lightness" from F73). It's all very
wooly and gappy. Because if the intent is strictly about people who have
issues with color perception / color blindness, the F73 escape clause
makes sense, and the understanding document needs to be updated.
Otherwise, F73 needs to be retired/clarified. And/or what counts as
another "visual" hint needs to be clarified...is it purely text-based
(implied by the mention of "text-only displays")? Because then even an
additional icon or border or different text visual treatment or similar
would not be sufficient to pass.
(This is the usual case of vague definitions which lead to far more
unexpected questions that were never intended when the SC/Understanding
were written).
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: glen walker
Date: Mon, Mar 09 2020 5:01AM
Subject: Re: 1.4.1 use of color for state indicator
← Previous message | Next message →
Ok, maybe I need to ask for an opinion, then.
If you had to audit a site and the selected button had a black or blue
background (unselected has a white background), would you pass 1.4.1? Or
perhaps report it as a low priority failure and recommend they add another
visual clue for the selected button but note that as it currently stands,
most (if not all) users that can see the buttons will be able to tell which
one is selected?
If so, then when would this issue move from a low to a medium or high
priority issue? I have a real example where the default button has a white
background (and black text) but the selected button in the group has a
light orange background. The contrast ratio of of the white to orange is
1.8:1, but as mentioned originally, there isn't a requirement for contrast
between states.
The buttons all have borders so the adjacent color contrast is ok (1.4.11).
Technically, the light orange background is "color only" just like the
black background, but it sounds like the black background we would pass.
So what would you use to determine when a 1.4.1 pass becomes a failure?
Contrast?
From: Patrick H. Lauke
Date: Mon, Mar 09 2020 5:18AM
Subject: Re: 1.4.1 use of color for state indicator
← Previous message | Next message →
On 09/03/2020 11:01, glen walker wrote:
> Ok, maybe I need to ask for an opinion, then.
>
> If you had to audit a site and the selected button had a black or blue
> background (unselected has a white background), would you pass 1.4.1? Or
> perhaps report it as a low priority failure and recommend they add another
> visual clue for the selected button but note that as it currently stands,
> most (if not all) users that can see the buttons will be able to tell which
> one is selected?
>
> If so, then when would this issue move from a low to a medium or high
> priority issue? I have a real example where the default button has a white
> background (and black text) but the selected button in the group has a
> light orange background. The contrast ratio of of the white to orange is
> 1.8:1, but as mentioned originally, there isn't a requirement for contrast
> between states.
>
> The buttons all have borders so the adjacent color contrast is ok (1.4.11).
>
> Technically, the light orange background is "color only" just like the
> black background, but it sounds like the black background we would pass.
>
> So what would you use to determine when a 1.4.1 pass becomes a failure?
> Contrast?
I've so far tackled this gap/inconsistency in WCAG using the 3:1
contrast ratio noted in F73
(https://www.w3.org/WAI/WCAG21/Techniques/failures/F73). Of course,
there's related things I'd look for in terms of "is the selection state
programmatically conveyed" under 4.1.2.
However, I've noted this gap before, and that the redefinition of
"color" to mean "hue" in a non-normative failure technique is
ridiculous. The actual normative 1.4.1 needs to be expanded/modified to
address these things, but currently the desire to open that can of worms
in WCAG seems low, unfortunately.
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Jonathan Avila
Date: Mon, Mar 09 2020 5:57AM
Subject: Re: 1.4.1 use of color for state indicator
← Previous message | Next message →
If something has contrast >= 3:1 then and that contrast communicates the meaning even when in grayscale then it would not fail the 1.4.1 Color requirement as Color (Hue) is not being used -- luminance is being used to communicate the difference.
So if you have a selected button that is inverted from the other colors and that selected state itself and the difference from the adjacent selected states >= 3:1 then it would pass. Comparison between non-adjacent selected states is something of a challenge as it's not clearly stated -- but I'd argue that if the difference between selected states only used luminance that was < 3:1 compared to the other selected state then it would not pass.
Jonathan
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: Monday, March 9, 2020 7:01 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] 1.4.1 use of color for state indicator
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Ok, maybe I need to ask for an opinion, then.
If you had to audit a site and the selected button had a black or blue background (unselected has a white background), would you pass 1.4.1? Or perhaps report it as a low priority failure and recommend they add another visual clue for the selected button but note that as it currently stands, most (if not all) users that can see the buttons will be able to tell which one is selected?
If so, then when would this issue move from a low to a medium or high priority issue? I have a real example where the default button has a white background (and black text) but the selected button in the group has a light orange background. The contrast ratio of of the white to orange is 1.8:1, but as mentioned originally, there isn't a requirement for contrast between states.
The buttons all have borders so the adjacent color contrast is ok (1.4.11).
Technically, the light orange background is "color only" just like the black background, but it sounds like the black background we would pass.
So what would you use to determine when a 1.4.1 pass becomes a failure?
Contrast?
From: glen walker
Date: Mon, Mar 09 2020 6:20AM
Subject: Re: 1.4.1 use of color for state indicator
← Previous message | Next message →
Thanks, Jonathan. That sounds nice but there's nothing in the success
criterion to imply that. It makes logical sense, but it's not spelled out
anywhere.
When you say "something" has a contrast greater than 3:1, is that something
the two states? Selected and unselected, even though they're not adjacent
colors?
As far as grayscale, I could take white and yellow, a contrast of 1.1, and
when viewed in grayscale, the yellow will be slightly gray. Are you saying
that would pass? Or are you saying convert the colors to grayscale first,
then take the ratio of the resulting grays and see if it's greater than 3:1?
When you get into hue vs luminance, it's hard to explain to
non-accessibility people (or maybe people in general) that 1.4.1 use of
*color* might not really mean color. Both red and pink are colors. Using
one for one meaning and the other for another meaning is using two colors.
Saying that doesn't fail 1.4.1 because they're not really colors, they're
luminance, just feels weird.
From: Steve Green
Date: Mon, Mar 09 2020 6:27AM
Subject: Re: 1.4.1 use of color for state indicator
← Previous message | Next message →
I don't agree with this view. Colour has two properties - hue and luminance, but neither is mentioned in either the normative text or the Understanding page. Only colour is mentioned.
F73 incorrectly states that hue is the same as colour and that luminance is not colour. This appears to be the only reference to hue, and it is factually wrong as well as being non-normative.
Steve Green
Managing Director
Test Partners Ltd
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Jonathan Avila
Sent: 09 March 2020 11:58
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] 1.4.1 use of color for state indicator
If something has contrast >= 3:1 then and that contrast communicates the meaning even when in grayscale then it would not fail the 1.4.1 Color requirement as Color (Hue) is not being used -- luminance is being used to communicate the difference.
So if you have a selected button that is inverted from the other colors and that selected state itself and the difference from the adjacent selected states >= 3:1 then it would pass. Comparison between non-adjacent selected states is something of a challenge as it's not clearly stated -- but I'd argue that if the difference between selected states only used luminance that was < 3:1 compared to the other selected state then it would not pass.
Jonathan
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: Monday, March 9, 2020 7:01 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] 1.4.1 use of color for state indicator
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Ok, maybe I need to ask for an opinion, then.
If you had to audit a site and the selected button had a black or blue background (unselected has a white background), would you pass 1.4.1? Or perhaps report it as a low priority failure and recommend they add another visual clue for the selected button but note that as it currently stands, most (if not all) users that can see the buttons will be able to tell which one is selected?
If so, then when would this issue move from a low to a medium or high priority issue? I have a real example where the default button has a white background (and black text) but the selected button in the group has a light orange background. The contrast ratio of of the white to orange is 1.8:1, but as mentioned originally, there isn't a requirement for contrast between states.
The buttons all have borders so the adjacent color contrast is ok (1.4.11).
Technically, the light orange background is "color only" just like the black background, but it sounds like the black background we would pass.
So what would you use to determine when a 1.4.1 pass becomes a failure?
Contrast?
From: Patrick H. Lauke
Date: Mon, Mar 09 2020 6:38AM
Subject: Re: 1.4.1 use of color for state indicator
← Previous message | Next message →
On 09/03/2020 12:27, Steve Green wrote:
> I don't agree with this view. Colour has two properties - hue and luminance, but neither is mentioned in either the normative text or the Understanding page. Only colour is mentioned.
>
> F73 incorrectly states that hue is the same as colour and that luminance is not colour. This appears to be the only reference to hue, and it is factually wrong as well as being non-normative.
Both the SC's understanding, and the non-normative F73 with its handwavy
"color = hue", are problematic. And, as pointed out, they're not
internally consistent. However, the escape clause in F73 has been cited
by current AGWG members before as a rationale/justification for this
type of interpretation.
As I say in that github issue, this really needs to be sorted out,
normatively.
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Jonathan Avila
Date: Mon, Mar 09 2020 6:41AM
Subject: Re: 1.4.1 use of color for state indicator
← Previous message | Next message →
If luminance was color then every single piece of content on a web page would be using color to communicate. Black text on a white background would be using color to communicate that it's text! A black border would be using color to communicate it's a border on a white background. The goal of the SC is to be able to differentiate -- if the author can differentiate sufficiently you can pass the criterion.
From the understanding docs -- "The intent of this Success Criterion is to ensure that all users can access information that is conveyed by color differences".
Jonathan
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Steve Green
Sent: Monday, March 9, 2020 8:27 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] 1.4.1 use of color for state indicator
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
I don't agree with this view. Colour has two properties - hue and luminance, but neither is mentioned in either the normative text or the Understanding page. Only colour is mentioned.
F73 incorrectly states that hue is the same as colour and that luminance is not colour. This appears to be the only reference to hue, and it is factually wrong as well as being non-normative.
Steve Green
Managing Director
Test Partners Ltd
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Jonathan Avila
Sent: 09 March 2020 11:58
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] 1.4.1 use of color for state indicator
If something has contrast >= 3:1 then and that contrast communicates the meaning even when in grayscale then it would not fail the 1.4.1 Color requirement as Color (Hue) is not being used -- luminance is being used to communicate the difference.
So if you have a selected button that is inverted from the other colors and that selected state itself and the difference from the adjacent selected states >= 3:1 then it would pass. Comparison between non-adjacent selected states is something of a challenge as it's not clearly stated -- but I'd argue that if the difference between selected states only used luminance that was < 3:1 compared to the other selected state then it would not pass.
Jonathan
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: Monday, March 9, 2020 7:01 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] 1.4.1 use of color for state indicator
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Ok, maybe I need to ask for an opinion, then.
If you had to audit a site and the selected button had a black or blue background (unselected has a white background), would you pass 1.4.1? Or perhaps report it as a low priority failure and recommend they add another visual clue for the selected button but note that as it currently stands, most (if not all) users that can see the buttons will be able to tell which one is selected?
If so, then when would this issue move from a low to a medium or high priority issue? I have a real example where the default button has a white background (and black text) but the selected button in the group has a light orange background. The contrast ratio of of the white to orange is 1.8:1, but as mentioned originally, there isn't a requirement for contrast between states.
The buttons all have borders so the adjacent color contrast is ok (1.4.11).
Technically, the light orange background is "color only" just like the black background, but it sounds like the black background we would pass.
So what would you use to determine when a 1.4.1 pass becomes a failure?
Contrast?
From: Jonathan Avila
Date: Mon, Mar 09 2020 6:49AM
Subject: Re: 1.4.1 use of color for state indicator
← Previous message | Next message →
Hi Glenn, yes -- you'd want to take the contrast ratio before converting to grayscale as the calculation treats hues differently to help people with color perception challenges -- but applying a simple grayscale test would help people understand if it's really the hue or the luminance that makes the difference. For example, if you grayscale something and it says find the red text then it's obviously an issue. If you grayscale something and then you say which of your buttons is selected -- then you'd say -- the color (hue) doesn't make difference (e.g. whether it's purple or blue didn't matter) -- I'm really looking at lightness making a difference. As I understand it luminance and lightness are not the same thing -- but lightness is a easier to understand concept for me and most people. So if you then say it's lightness that makes a difference based on my grayscale tests -- then I go back to color and check the contrast ratio between the two items. So if the selected state only
relied on color difference -- does that selected state have >= 3:1 (I should have said >= in my prior email)?
Jon
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: Monday, March 9, 2020 8:21 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] 1.4.1 use of color for state indicator
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Thanks, Jonathan. That sounds nice but there's nothing in the success criterion to imply that. It makes logical sense, but it's not spelled out anywhere.
When you say "something" has a contrast greater than 3:1, is that something the two states? Selected and unselected, even though they're not adjacent colors?
As far as grayscale, I could take white and yellow, a contrast of 1.1, and when viewed in grayscale, the yellow will be slightly gray. Are you saying that would pass? Or are you saying convert the colors to grayscale first, then take the ratio of the resulting grays and see if it's greater than 3:1?
When you get into hue vs luminance, it's hard to explain to non-accessibility people (or maybe people in general) that 1.4.1 use of
*color* might not really mean color. Both red and pink are colors. Using one for one meaning and the other for another meaning is using two colors.
Saying that doesn't fail 1.4.1 because they're not really colors, they're luminance, just feels weird.
From: Steve Green
Date: Mon, Mar 09 2020 6:50AM
Subject: Re: 1.4.1 use of color for state indicator
← Previous message | Next message →
Luminance isn't colour either. Every definition of colour I can find states that colour is the combination of hue and luminance. All the research into colour perception involves both hue and luminance, and the WAI colour contrast algorithm is based on both.
If the SC does not say what its authors meant it to say, then it needs to be rewritten. In the meantime, I do not see any justification for ignoring luminance. FWIW, I would argue against any change in the SC that equates hue to colour.
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Jonathan Avila
Sent: 09 March 2020 12:42
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] 1.4.1 use of color for state indicator
If luminance was color then every single piece of content on a web page would be using color to communicate. Black text on a white background would be using color to communicate that it's text! A black border would be using color to communicate it's a border on a white background. The goal of the SC is to be able to differentiate -- if the author can differentiate sufficiently you can pass the criterion.
From the understanding docs -- "The intent of this Success Criterion is to ensure that all users can access information that is conveyed by color differences".
Jonathan
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Steve Green
Sent: Monday, March 9, 2020 8:27 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] 1.4.1 use of color for state indicator
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
I don't agree with this view. Colour has two properties - hue and luminance, but neither is mentioned in either the normative text or the Understanding page. Only colour is mentioned.
F73 incorrectly states that hue is the same as colour and that luminance is not colour. This appears to be the only reference to hue, and it is factually wrong as well as being non-normative.
Steve Green
Managing Director
Test Partners Ltd
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Jonathan Avila
Sent: 09 March 2020 11:58
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] 1.4.1 use of color for state indicator
If something has contrast >= 3:1 then and that contrast communicates the meaning even when in grayscale then it would not fail the 1.4.1 Color requirement as Color (Hue) is not being used -- luminance is being used to communicate the difference.
So if you have a selected button that is inverted from the other colors and that selected state itself and the difference from the adjacent selected states >= 3:1 then it would pass. Comparison between non-adjacent selected states is something of a challenge as it's not clearly stated -- but I'd argue that if the difference between selected states only used luminance that was < 3:1 compared to the other selected state then it would not pass.
Jonathan
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: Monday, March 9, 2020 7:01 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] 1.4.1 use of color for state indicator
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Ok, maybe I need to ask for an opinion, then.
If you had to audit a site and the selected button had a black or blue background (unselected has a white background), would you pass 1.4.1? Or perhaps report it as a low priority failure and recommend they add another visual clue for the selected button but note that as it currently stands, most (if not all) users that can see the buttons will be able to tell which one is selected?
If so, then when would this issue move from a low to a medium or high priority issue? I have a real example where the default button has a white background (and black text) but the selected button in the group has a light orange background. The contrast ratio of of the white to orange is 1.8:1, but as mentioned originally, there isn't a requirement for contrast between states.
The buttons all have borders so the adjacent color contrast is ok (1.4.11).
Technically, the light orange background is "color only" just like the black background, but it sounds like the black background we would pass.
So what would you use to determine when a 1.4.1 pass becomes a failure?
Contrast?
From: Jonathan Avila
Date: Mon, Mar 09 2020 6:54AM
Subject: Re: 1.4.1 use of color for state indicator
← Previous message | Next message →
> All the research into colour perception involves both hue and luminance, and the WAI colour contrast algorithm is based on both.
Yes, the contrast ratio does take into account more than lightness -- to help users with color perception challenges. That's why a contrast of >= 3:1 should be sufficient as it takes into account these other aspects.
Jonathan
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Steve Green
Sent: Monday, March 9, 2020 8:50 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] 1.4.1 use of color for state indicator
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Luminance isn't colour either. Every definition of colour I can find states that colour is the combination of hue and luminance. All the research into colour perception involves both hue and luminance, and the WAI colour contrast algorithm is based on both.
If the SC does not say what its authors meant it to say, then it needs to be rewritten. In the meantime, I do not see any justification for ignoring luminance. FWIW, I would argue against any change in the SC that equates hue to colour.
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Jonathan Avila
Sent: 09 March 2020 12:42
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] 1.4.1 use of color for state indicator
If luminance was color then every single piece of content on a web page would be using color to communicate. Black text on a white background would be using color to communicate that it's text! A black border would be using color to communicate it's a border on a white background. The goal of the SC is to be able to differentiate -- if the author can differentiate sufficiently you can pass the criterion.
From the understanding docs -- "The intent of this Success Criterion is to ensure that all users can access information that is conveyed by color differences".
Jonathan
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Steve Green
Sent: Monday, March 9, 2020 8:27 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] 1.4.1 use of color for state indicator
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
I don't agree with this view. Colour has two properties - hue and luminance, but neither is mentioned in either the normative text or the Understanding page. Only colour is mentioned.
F73 incorrectly states that hue is the same as colour and that luminance is not colour. This appears to be the only reference to hue, and it is factually wrong as well as being non-normative.
Steve Green
Managing Director
Test Partners Ltd
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Jonathan Avila
Sent: 09 March 2020 11:58
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] 1.4.1 use of color for state indicator
If something has contrast >= 3:1 then and that contrast communicates the meaning even when in grayscale then it would not fail the 1.4.1 Color requirement as Color (Hue) is not being used -- luminance is being used to communicate the difference.
So if you have a selected button that is inverted from the other colors and that selected state itself and the difference from the adjacent selected states >= 3:1 then it would pass. Comparison between non-adjacent selected states is something of a challenge as it's not clearly stated -- but I'd argue that if the difference between selected states only used luminance that was < 3:1 compared to the other selected state then it would not pass.
Jonathan
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: Monday, March 9, 2020 7:01 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] 1.4.1 use of color for state indicator
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Ok, maybe I need to ask for an opinion, then.
If you had to audit a site and the selected button had a black or blue background (unselected has a white background), would you pass 1.4.1? Or perhaps report it as a low priority failure and recommend they add another visual clue for the selected button but note that as it currently stands, most (if not all) users that can see the buttons will be able to tell which one is selected?
If so, then when would this issue move from a low to a medium or high priority issue? I have a real example where the default button has a white background (and black text) but the selected button in the group has a light orange background. The contrast ratio of of the white to orange is 1.8:1, but as mentioned originally, there isn't a requirement for contrast between states.
The buttons all have borders so the adjacent color contrast is ok (1.4.11).
Technically, the light orange background is "color only" just like the black background, but it sounds like the black background we would pass.
So what would you use to determine when a 1.4.1 pass becomes a failure?
Contrast?
From: Mallory
Date: Mon, Mar 09 2020 10:35AM
Subject: Re: 1.4.1 use of color for state indicator
← Previous message | Next message →
I have failed that kind of inverse switching under Use of Color. If it's really supposed to be "Use of Color Unless A Minimum 3:1 Contrast" then someone should change it to that. And they should remove this group of people from the Benefits section:
...
"People using text-only, limited color, or monochrome displays may be unable to access color-dependent information."
None of those use-cases will be helped by some minimum contrast level, regardless of whether colour is a hue or a luminosity or a bottle of Toilet Duck.
For a client who wants to actually be accessible to real-life users, I would absolutely create a bug ticket for that (and I have, and I will continue to do so). Someone already mentioned a user stylesheet. I'm a Windows High Contrast user, but more broadly the concept is "limited colour palette" (and does not have to imply a high contrast at all. You can use limited colour palettes to *lower* contrast, which some people require).
I run into "pressed/selected items are denoted by a change of colours only" aaaall the time (esp custom dropdown menus), and in practice you have to turn off your WHC or personal stylesheet or whatever in order to visually determine that state.
[I said a lot more things, then took a swig of whisky and deleted it]
mouth-foamingly yours,
_mallory
From: Patrick H. Lauke
Date: Mon, Mar 09 2020 11:32AM
Subject: Re: 1.4.1 use of color for state indicator
← Previous message | Next message →
On 09/03/2020 16:35, Mallory wrote:
> I have failed that kind of inverse switching under Use of Color. If it's really supposed to be "Use of Color Unless A Minimum 3:1 Contrast" then someone should change it to that. And they should remove this group of people from the Benefits section:
> ...
> "People using text-only, limited color, or monochrome displays may be unable to access color-dependent information."
>
> None of those use-cases will be helped by some minimum contrast level, regardless of whether colour is a hue or a luminosity or a bottle of Toilet Duck.
I would rather guess that when writing the benefits, people got very
overzealous and did not consider the more fundamental
meaning/implications of what they were writing. Back in 2000 or whenever
that SC was crafted.
Which is why I've pressed the matter there in github.
> For a client who wants to actually be accessible to real-life users, I would absolutely create a bug ticket for that (and I have, and I will continue to do so). Someone already mentioned a user stylesheet. I'm a Windows High Contrast user, but more broadly the concept is "limited colour palette" (and does not have to imply a high contrast at all. You can use limited colour palettes to *lower* contrast, which some people require).
>
> I run into "pressed/selected items are denoted by a change of colours only" aaaall the time (esp custom dropdown menus), and in practice you have to turn off your WHC or personal stylesheet or whatever in order to visually determine that state.
If you go down the WHCM/custom stylesheet route, though, ANY kind of
visual distinction (even without color - whether you take it as "hue
only" or the stricter "hue and luminance") such as borders, extra
outlines, CSS-generated symbols, etc will potentially/usually fall by
the wayside. And then the SC really becomes "you must denote this in
pure HTML text". Which is not what the intention of the SC was. But
agree that this is where we have the "WCAG vs actual real-life
accessibility for all users" tension, as usual.
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Mallory
Date: Tue, Mar 10 2020 6:34AM
Subject: Re: 1.4.1 use of color for state indicator
← Previous message | Next message →
Some thoughts:
Use of Color claims to be a sub-set of "forms of perception" (esp under 1.3.3 which unfortunately strictly limits itself mostly to textual instructions, when in real life designers have been relying on visual recognition/intuition to self-explain how a lot of content and interactives work, for years), so I would not include things like borders, outlines, symbols, etc. I would even wager the "reasonable man" would not either.
Perhaps naïve, but it seems easy to take Use of Color and read it to mean "color" and not "vision"; stretching it to such seems disingenuous. Again, whether that's hue or luminosity or Toilet Duck aside. While people can argue on hue vs luminosity, taking it to borders and symbols just seems a bit silly when you take a step back. Ask 100 people what "colour" means and while you're sure to get a variety of answers, borders/outlines/images are very unlikely to be in that.
"but everything is technically nothing more than coloured pixels on a screen" would not be a useful degradation of terms. That we must cross half of a distance to somewhere in order to reach it, infinitely, and thus technically can never reach any destination is another example of not being useful. People reach destinations. People who can see, don't always see colour. If my user stylesheet changes more than colour, then it's outside this SC anyway, isn't it?
If I have *no* vision, I have assistive technology to access the text-based alternative (if that's what there is), but the Use of Color seems to me directly to people who DO have vision, use their vision, and rely on their vision; and because relying on colour is something devs and designers seem to specifically do a lot AND apparently forget about AND need a dedicated SC shoved in their faces to stop relying on colour alone to convey info.
I wonder if that legal term "reasonable man" can be a part of at least higher level readings of the future WCAG 3? It would of course be discarded for those who need to go further in depth because they are developing, or writing tests, or whatever.
still foaming a bit,
_mallory
On Mon, Mar 9, 2020, at 6:32 PM, Patrick H. Lauke wrote:
...
> If you go down the WHCM/custom stylesheet route, though, ANY kind of
> visual distinction (even without color - whether you take it as "hue
> only" or the stricter "hue and luminance") such as borders, extra
> outlines, CSS-generated symbols, etc will potentially/usually fall by
> the wayside. And then the SC really becomes "you must denote this in
> pure HTML text". Which is not what the intention of the SC was. But
> agree that this is where we have the "WCAG vs actual real-life
> accessibility for all users" tension, as usual.
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
From: Patrick H. Lauke
Date: Tue, Mar 10 2020 8:07AM
Subject: Re: 1.4.1 use of color for state indicator
← Previous message | No next message
On 10/03/2020 12:34, Mallory wrote:
> Use of Color claims to be a sub-set of "forms of perception" (esp under 1.3.3 which unfortunately strictly limits itself mostly to textual instructions, when in real life designers have been relying on visual recognition/intuition to self-explain how a lot of content and interactives work, for years), so I would not include things like borders, outlines, symbols, etc. I would even wager the "reasonable man" would not either.
>
> Perhaps naïve, but it seems easy to take Use of Color and read it to mean "color" and not "vision"; stretching it to such seems disingenuous. Again, whether that's hue or luminosity or Toilet Duck aside. While people can argue on hue vs luminosity, taking it to borders and symbols just seems a bit silly when you take a step back. Ask 100 people what "colour" means and while you're sure to get a variety of answers, borders/outlines/images are very unlikely to be in that.
>
> "but everything is technically nothing more than coloured pixels on a screen" would not be a useful degradation of terms. That we must cross half of a distance to somewhere in order to reach it, infinitely, and thus technically can never reach any destination is another example of not being useful. People reach destinations. People who can see, don't always see colour. If my user stylesheet changes more than colour, then it's outside this SC anyway, isn't it?
>
> If I have *no* vision, I have assistive technology to access the text-based alternative (if that's what there is), but the Use of Color seems to me directly to people who DO have vision, use their vision, and rely on their vision; and because relying on colour is something devs and designers seem to specifically do a lot AND apparently forget about AND need a dedicated SC shoved in their faces to stop relying on colour alone to convey info.
But all this is my point for why the understanding document, which lists
Braille displays and text-only displays, is wrong to list them. So we're
agreed it's about vision/visible things (leaving Braille/text-only to
the side).
Now, people not being able to perceive color changes is different from
people not being able to perceive something as dramatic as a total
inversion of foreground/background, or some very strong changes in
contrast ratio, I would argue. Which I think is what - based on pushback
at the time of publication when 2.0 came out - led to that escape clause
in F73 that brought contrast into play and that by the backdoor
redefinition of "color = hue".
But it all comes down, to me, to the problem that:
- the SC itself says one thing, while its understanding doc currently
implies other things
- the escape clause about contrast is hidden away in a technique - if it
really is valid, it should be promoted to be part of the actual
understanding at least (while still debatable, at least it's a debate
that we're more likely to have, rather than something that's hidden away
in a technique that only few people really took the time to spot)
As for the "reasonable man" ... I really wish WCAG was more nuanced, and
that it could be applied/evaluated with nuance. Sadly, currently, the
binary nature of pass/fail, and the fact that some legislations have
basically taken it as the benchmark for pass/fail, makes it problematic
to allow for nuance, which is why we end up with arbitrary lines in the
sand, over-complex definitions that try to still unambiguously define
something that requires far more contextual evaluation, etc.
But anyway, that's me just rattling off my a11yTO talk again...
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke