Re: SC 1.4.11

Hi Wilco,

The actual normative text states:

Success Criterion 1.4.11 Non-text Contrast (Level AA)

The visual presentation of the following have a contrast ratio of at least
3:1 against adjacent color(s):

*User Interface Components*
    Visual information required to identify user interface components and
states, except for inactive components or where the appearance of the
component is determined by the user agent and not modified by the author;

*Graphical Objects*
    Parts of graphics required to understand the content, except when a
particular presentation of graphics is essential to the information being
conveyed.




Respectfully, I disagree with your reading. The "narrow" and "wide" terms
are not mine BTW, they are being use to differentiate the conflicting
interpretations. My argument is based on the normative language, which I've
previously explained:

The SC exception states:

*​​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 items, as they have different definitions. They are
also separate because of the joiner 'AND', as in Peanut Butter AND Jelly:
frequently seen together, but not obligated to be so.)

My argument against the 'narrow' (I actually see it as "permissive")
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), because if that was the intent
would have (should have?) then had the following exception language:

*​...*except for inactive components or where the appearance of the
component *and/or state* is determined by the user agent and not modified
by the author;

​
Visible tab focus is a state and not a component;​ it is already defined
separately from component, *and state is not called out in the exception*,
only the component, so (I argue) it is excluded from the exception.


So putting aside "narrow" and "wide", this is an exact and precise reading
of the normative text:

"...or where the appearance of the *component* is determined by the user
agent and not modified by the author".

I can understand the
​counter-​
argument of "that is not what we meant when we wrote it", but it IS how it
reads today.



​> It (WCAG) defines what parts of web accessibility are the responsibility
of authors.​

Fair enough. To re-state that, on today's Web:

   - the choice of text and images of text are the responsibility of the
   author

   - the choice of active images (including icons) are the responsibility
   of the author

   - the choice of other design decisions (including all choices of colors
   - the entire color palette, both foreground and background colors and the
   contrast between them all) are the responsibility of the author.

   (As 'proof':  we often point to pie-charts, where we tell authors that
   each slice of pie must have a contrast of 3:1 to the adjacent slices, and
   that all of the slices must also have a contrast of 3:1 against the
   background. And if you overlay text on those slices, the text must also
   have sufficient contrast to it's directly corresponding background color as
   well.)


Let's unpack that some more:

   - If you change the background color to a dark color, you are
   responsible for changing the text or images of text colors as well, to be
   in compliance to WCAG.

   - With 1.4.11, if you change the background color to a dark color, you
   are responsible for ensuring any active image is also modified to meet
   contrast, to be in compliance to WCAG.

   - ...and so the "wide" (I'd call it "precise") argument is, if you
   change the background color, then any and all subsequent CONTRAST decisions
   are your responsibility as well, to be in compliance to WCAG.

​Now, I agree that the normative text could have been made clearer (I asked
if we could fix that on the last call, a scary question, but the apparent
answer is not really...), and so it is left to the Understanding and
Techniques support materials to illustrate the intent​, which is that *critical
visual information have sufficient contrast* to meet the needs of those
user who require sufficient contrast. Frankly, I'd rather we strengthen
what our intention was, rather than roll back to an interpretation that
does not meet our initial goals and intent, which is what some are
proposing now.

What happens if we remove the second exception and re-formulate the same
text today? (thought exercise only)

The visual presentation of the following *information required to identify
user interface components and states* have a contrast ratio of at least 3:1
against adjacent color(s), except for inactive components or where the
appearance of the *component *is determined by the user agent and not
modified by the author. (NOTE, I did not change any of the text, I simply
omitted some of the original text and moved the first bullet up to be part
of the sentence.)

​In that reformulation​, it seems quite clear to me that "states" was
omitted from the exception, and so I continue to struggle why others cannot
see this as clearly.

JF




On Wed, Jun 20, 2018 at 3:56 PM, Wilco Fiers <wilco.fiers@deque.com> wrote:

> 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
>



-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion