Re: SC 1.4.11

Eric, John,
You're correct in this very literal reading of the SC. It effectively says
that if you change anything at all about a component, you are now fully in
responsible for its presentation. Not just focus, everything. This
argument, taken to its natural conclusion would mean that if someone sets
the background of the page, they are now responsible for the contrast of
checkboxes and radio buttons and those arrows in select. On a white
background, those things in Chrome have a contrast of 2.9:1.

It seems obvious to me that components like this are exempt from this SC.
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. The literal reading of
the text is inconsistent with one of the things this SC is trying to do:
Allow an exception in the case where the browser, not the author should
have ensured sufficient contrast. You can't make that argument for focus
and have it not apply to all other state indicators and element boundaries.

W

On Thu, Jun 21, 2018 at 9:25 AM Eric Eggert <ee@w3.org> wrote:

> *(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:
>
> <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:
>
> <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)
>


-- 
*Wilco Fiers*
Senior Accessibility Engineer - Co-facilitator WCAG-ACT - Chair Auto-WCAG