W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2018

RE: SC 1.4.11

From: Alastair Campbell <acampbell@nomensa.com>
Date: Thu, 21 Jun 2018 16:19:46 +0000
To: John Foliot <john.foliot@deque.com>
CC: GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
Message-ID: <AM5PR0902MB200280A9466D7495038D6D30B9760@AM5PR0902MB2002.eurprd09.prod.outlook.com>
A couple of follow ups:

> The Mantra is actually quite simple: if you adjust the background color(s), you must adjust the foreground color(s) as well

But focus indicators (at least the outline-style used by browsers) isn’t a foreground colour. It is another colour tacked on the outside of the component. It is something added around the component.

E.g. One of the key discussion points we had in LVTF was that it could contrast with either the component or the background, otherwise it would be infeasible (the 3-way color contrast issue).

> As Patrick noted<https://lists.w3.org/Archives/Public/w3c-wai-gl/2018AprJun/0753.html>, this was also the intent of this SC going back historically, as Alastair essentially confirmed to Patrick last September<https://github.com/w3c/wcag/issues/302#issuecomment-326996680>.

I confirmed the general intent of the SC, we hadn’t really drilled into the area of browser defaults for the exception then.

> I will also argue that from a 'teaching' perspective that's a fairly easy concept to convey, and from a testing perspective, we no no longer have to test multiple browser/OS/AT combinations, we simply have to test for author intent (i.e. examine/inspect the CSS in the DOM)

There are plenty of sites which use *{outline:0;} to fail WCAG 2.0, and there are plenty that haven’t defined anything, so I think testers for general public sites would have to work out which background colours are ‘safe’. (I think dark backgrounds probably pass with default indicators at the moment?)
And it could change over time, leading to your least favourite thing – pages where conformance changes due to passing of time.

> I'm not 100% sure what you mean by a "non-UI Component" (aren't all components part of the UI?),

I’d go with ‘interactive’ components as a substitute of meaning, a table wouldn’t be a UI component, but sortable-buttons on a table would be.

>>In this case the UI element (the button) was not modified by the author, so it’s covered by the exception and would pass.

It took me a little while to realise Eric meant that the background showing through the link changed the component.
However, John’s view (I think) is that both the button and link would fail because they have a background set. The background around the component changes the component because it is to do with contrast.

That’s partly why I referred to it as the “wide” interpretation, so I guess we have three now:

-          Wide: There is no exception if colour is changed around the component, or if the component itself is changed;

-          Literal: Anything about the component changes, but not including the background around it.

-          Narrow, only the focus state is overridden (for focus state change).

I think Wilco’s reading of it will be very common for devs:
> “Setting the page background, or the size of a checkbox, or the font in a select, should not mean that at that point the author is responsible for styling the entire component in every user agent.”

We’ll be fighting the tide otherwise.

Received on Thursday, 21 June 2018 16:20:13 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:26 UTC