Re: SC 1.4.11

John,
There is no "narrow interpretation" here. This discussion wasn't framed
very well, which is creating a lot of confusion (and I hope the chairs take
note). WCAG isn't the same as web accessibility. It defines what parts of
web accessibility are the responsibility of authors. Nobody is arguing that
low contrast focus rings aren't a problem. The question that matters is if,
based on the normative text that we all agreed on, a convincing argument
can be made to support the "wide interpretation". And so far, I haven't
been convinced by the arguments, and neither have many others.

I totally get what you are saying about browsers and background and PwD,
but it doesn't really matter why you think something should be a violation,
if you can't back it up with a convincing argument based on normative text.
The burden of proof is on the person(s) claiming something is in violation.
Not the other way around.

W

On Wed, Jun 20, 2018 at 8:22 PM John Foliot <john.foliot@deque.com> wrote:

> Patrick,
>
> I may have not explained this as well as I had hoped. With the narrow
> interpretation, the problem scenario you outlined exists: different results
> in different browsers, so instead we don't test because "user-agent issue".
>
> With the wide interpretation, you aren't testing for browser
> implementations, you are testing for author intent and what has been
> created by the author, which is actually (I will suggest) easier to test
> for - it removes browser inconsistencies from the mix by effectively
> starting out at the point where the browser is more likely wrong (and not,
> instead, hoping that the browser got it right).
>
> I don't have ready access to a Mac today, but testing my example page
> <http://john.foliot.ca/demos/SC_1_4_11.html> in Firefox, FF got it right.
> Testing it in Chrome, Chrome got it wrong. Anecdotally today, Safari is
> like Chrome - it gets it wrong as well (happy to be proven otherwise
> however).
>
> Given that there is a likelihood that 2 of the 3 most popular browsers in
> use today are getting this wrong, I cannot walk away with a ¯\_(ツ)_/¯ "It's
> the browser's fault" response.
>
> JF
>
> On Wed, Jun 20, 2018 at 12:56 PM, John Foliot <john.foliot@deque.com>
> 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
>>
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com
>
> Advancing the mission of digital accessibility and inclusion
>


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