Re: Color Contrast (was RE: Coming to a decision on 2.2 - which has long since been lost in this thread)

I guess that is where interpretation is different.

2.4.7 explicitly states "for any keyboard operable control". If it fails 
2.1.1 it is not keyboard operable and 2.4.7 does not apply.

Regards,
James



On 2/24/2016 10:50 AM, Katie Haritos-Shea wrote:
>
> For me, absolutely, if you are going to the nth degree.
>
> Katie Haritos-Shea
> 703-371-5545
>
> On Feb 24, 2016 10:01 AM, "Jonathan Avila" <jon.avila@ssbbartgroup.com 
> <mailto:jon.avila@ssbbartgroup.com>> wrote:
>
>     ØWe must be talking about different things. What I am saying, for
>     example; a non-text interactive control must meet multiple SC, not
>     one, not just 4.1.2 or 1.1.1 or 2.4.7 - but all of them (and quite
>     a few more).
>
>     Ah, yes, now I understand what you are saying.
>
>     Generally agree!  Next question might be if something is not
>     keyboard accessible for not being focusable (SC 2.1.1) then does
>     it also fail SC 2.4.7 (Focus Visible)?  If I fail something on
>     2.1.1 for not being focusable I would not generally fail it on 2.4.7.
>
>     Jonathan
>
>     *From:*Katie Haritos-Shea [mailto:ryladog@gmail.com
>     <mailto:ryladog@gmail.com>]
>     *Sent:* Wednesday, February 24, 2016 12:50 PM
>     *To:* Jonathan Avila
>     *Cc:* John Foliot; WCAG
>     *Subject:* RE: Re[2]: Color Contrast (was RE: Coming to a decision
>     on 2.2 - which has long since been lost in this thread)
>
>     Jon,
>
>     We must be talking about different things. What I am saying, for
>     example; a non-text interactive control must meet multiple SC, not
>     one, not just 4.1.2 or 1.1.1 or 2.4.7 - but all of them (and quite
>     a few more).
>
>     And failure to meet any of those would be individual failures. How
>     one reports those failures can be accomplished in any number of
>     ways. But how we explain the failures informs both developers, QA
>     and others.
>
>     Katie Haritos-Shea
>     703-371-5545 <tel:703-371-5545>
>
>     On Feb 24, 2016 8:06 AM, "Jonathan Avila"
>     <jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com>>
>     wrote:
>
>     ØThe 'merging' (in my mind 'combining' or just 'use') of all
>     relevant SC to  specific components/content-types/elements is
>     always how I have applied WCAG 2. I have been very surprised that
>     others *don't* do it that way....
>
>     I would certainly flag these as “issues” and indicate that they
>     need to be fixed – but strictly speaking there would be a
>     “advisory” caveat per the same way the understanding document
>     lists these as advisory.    It is our recommendation that they be
>     addressed but when it comes to technical conformance they may not
>     pose a failure.  They likely pose a risk to organizations and that
>     alone is sufficient to make sure they are addressed.
>
>     Jonathan
>
>     *From:*Katie Haritos-Shea [mailto:ryladog@gmail.com
>     <mailto:ryladog@gmail.com>]
>     *Sent:* Wednesday, February 24, 2016 10:56 AM
>     *To:* John Foliot
>     *Cc:* David MacDonald; Léonie Watson; Sailesh Panchang; Andrew
>     Kirkpatrick; GLWAI Guidelines WG org; Gregg Vanderheiden RTF;
>     Jason J White; Paul J. Adam; Jim Allan; josh@interaccess.ie
>     <mailto:josh@interaccess.ie>; Jonathan Avila
>     *Subject:* RE: Re[2]: Color Contrast (was RE: Coming to a decision
>     on 2.2 - which has long since been lost in this thread)
>
>     The 'merging' (in my mind 'combining' or just 'use') of all
>     relevant SC to  specific components/content-types/elements is
>     always how I have applied WCAG 2. I have been very surprised that
>     others *don't* do it that way....
>
>     Katie Haritos-Shea
>     703-371-5545 <tel:703-371-5545>
>
>     On Feb 24, 2016 7:15 AM, "John Foliot" <john.foliot@deque.com
>     <mailto:john.foliot@deque.com>> wrote:
>
>     Jonathan Avila wrote:
>     >
>     > > Why do you consider it a loophole? Is it not understood that
>     for focus
>     > > indicators need to satisfy colour contrast/luminosity ratios?
>     >
>     > We seem to all agree they should but this does not seem to be
>     directly
>     covered
>     > by the success criteria.
>
>     +1
>     While we, as "experts" understand this, it is not specifically
>     called out as
>     part of the requirement(s) - thus the gap (I consider it more of a
>     gap than
>     a "loophole") is something that should be addressed going forward,
>     either
>     via work from one of the TFs currently working (Low Vision perhaps?)
>
>
>     > I believe a similar missing need exists When selection and focus are
>     indicated by
>     > the difference in luminosity of background and not by shape.   
>     Consider a
>     > selected page tab that was medium gray and the others a light
>     gray.   The
>     > selected state is indicated by color difference and it's not
>     clear if SC
>     1.4.1 would
>     > apply.  Even if it did apply and some other marking was added
>     there is no
>     > requirement that the marking have sufficient contrast.
>
>     Hear, hear.... with the caveat that color alone is not the only
>     means of
>     providing that kind of visual feedback, so it is actually a
>     "merging" (as it
>     were) of both 1.4.1 AND the variant of 1.4.3 under discussion here
>
>
>     > Future updates or extensions need to clearly address luminosity
>     for visual
>     > indication of keyboard focus and address color differences used for
>     selection.
>
>     +1
>
>     JF
>

-- 
Regards, James

Oracle <http://www.oracle.com>
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1 415 987 
1918 <tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com 
<sip:james.nurthen@oracle.com>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment