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

And as far as testing and remediation goes, it tells developers and
designers what they need to fix...

Katie Haritos-Shea
703-371-5545
On Feb 24, 2016 8:15 PM, "John Foliot" <john.foliot@deque.com> wrote:

> Hi Gregg,
>
>
>
> Yes in theory, but there are also times when reporting all SC failures
> (say, into a bug tracker) is also preferable (or at least desirable), so
> the answer isn’t always black or white there: it depends on how any one
> person is using the results of a given Success Criteria.
>
>
>
> JF
>
>
>
> *From:* Gregg Vanderheiden [mailto:gregg@raisingthefloor.org]
> *Sent:* Wednesday, February 24, 2016 6:34 PM
> *To:* Jonathan Avila <jon.avila@ssbbartgroup.com>
> *Cc:* Katie Haritos-Shea <ryladog@gmail.com>; John Foliot <
> john.foliot@deque.com>; GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
> *Subject:* Re: Color Contrast (was RE: Coming to a decision on 2.2 -
> which has long since been lost in this thread)
>
>
>
> it really doesn’t matter how many SC it fails for the same person does it?
>
>
>
>
> We tried to not cover the same issue three ways.   So a failure of any one
> for a person- is a failure to be accessible.   Something that fails three
> for a person is not more inaccessible than one to a person.  Kind of like a
> person having by a chain.   If one link fails or three — they still fall.
>
>
>
> No?
>
>
>
>
> *gregg*
>
>
>
> On Feb 24, 2016, at 12:01 PM, Jonathan Avila <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 <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
>
> On Feb 24, 2016 8:06 AM, "Jonathan Avila" <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]
> *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; 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
>
> On Feb 24, 2016 7:15 AM, "John Foliot" <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
>
>
>