Re: SC 1.4.11

**(W3C hat off)**

I think the literal read of the SC clearly says:

* 3:1 contrast ratio for all UI Components and their* states, except 
when the component is not modified by the author.

In your example, you changed the text/icon color, so the component is 
modified, hence the author needs to be sure to adhere to the 3:1 
contrast for the states as well.

(* Can non-UI Components have states?)

Now the interesting case is the following:

```html
<div style="background-color: blue;">
 <button>Click me!</button>
</div>
```

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

On the other hand:

```html
<div style="background-color: blue;">
 <a href="https://linktonowhere.example.com">Click me!</a>
</div>
```

Would not pass in my literal interpretation of the SC because the link 
is not only defined by the user agent but through inheriting the 
author’s background color. (In this case you need to change the color 
of the link anyway because it would not conform to text contrast, 
because links are blue by default.)

(Codepen: https://codepen.io/yatil/pen/rKddZW)

I wonder if this is also the interpretation of the group and if we can 
make it clearer in the Understanding documents…

Eric

On 20 Jun 2018, at 19:56, John Foliot wrote:

> Hi Patrick,
>
> I don't disagree, which is why I would like to see the 
> *interpretation* for
> this SC unambiguously state that you need to test for all possible
> browsers: that if you've not modified all foreground colors (including
> state) when you've modified the background then there is a likelihood 
> this
> will fail somewhere.
>
> The SC and exception state:
>
> *​​User Interface Components*
> *​:* ​
> Visual information required to identify user interface components
> <https://www.w3.org/TR/WCAG21/#dfn-user-interface-components> and 
> states
> <https://www.w3.org/TR/WCAG21/#dfn-states>
> ​*​
> , except for inactive components or where the appearance of the 
> component
> is determined by the user agent and not modified by the author;
>
> ​(* these are separate, as they have different definitions)
>
> My argument against the narrow interpretation is that we've explicitly
> defined both components AND states as requiring sufficient 
> contrast​, but
> the exception ONLY applies to components (and not explicitly states), 
> which
> if that was the intent would have then had the following exception 
> language:
>
> *​User Interface Components*
> *​:* ​
> Visual information required to identify user interface components and
> states, except for inactive components or where the appearance of the
> component *or state* is determined by the user agent and not modified 
> by
> the author;
>
> ​
> Visible tab focus is a state​, and that is not called out in the 
> exception,
> so it is exempt from the exception. I've always read this as being for
> components like an un-styled submit button.
>
> I've updated my example page at: 
> http://john.foliot.ca/demos/SC_1_4_11.html to
> capture this as well.
>
> JF
>
> On Wed, Jun 20, 2018 at 12:29 PM, Patrick H. Lauke 
> <redux@splintered.co.uk>
> wrote:
>
>> Of course, the problem is that it IS down to the browser whether 
>> something
>> passes or fails otherwise. And then, you'd have define clearly which
>> browsers to target/test in. Where do you draw the line? What if in 
>> one
>> browser, by default, the contrast of the focus indication is too low, 
>> but
>> in all others it's fine out of the box? Is that a fail, dependent on 
>> the
>> market share of the browser?
>>
>> This is the sort of thing that a best practice is much better suited 
>> to
>> tackle than a hard binary pass/fail, I'd say.
>>
>> P
>> --
>> Patrick H. Lauke
>>
>> www.splintered.co.uk | https://github.com/patrickhlauke
>> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>
>>
>
>
> -- 
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com
>
> Advancing the mission of digital accessibility and inclusion





--

Eric Eggert
Web Accessibility Specialist
Web Accessibility Initiative (WAI) at World Wide Web Consortium (W3C)