Re: SC 1.4.11

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/demo
> s/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