- From: Katie Haritos-Shea <ryladog@gmail.com>
- Date: Wed, 24 Feb 2016 13:50:28 -0500
- To: Jonathan Avila <jon.avila@ssbbartgroup.com>
- Cc: WCAG <w3c-wai-gl@w3.org>, John Foliot <john.foliot@deque.com>
- Message-ID: <CAEy-OxFR1ff5WYg3EC0o1_-evvr7m=TpYDQMY7c_XxT-gyTY4w@mail.gmail.com>
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> 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] > *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 >
Received on Wednesday, 24 February 2016 18:50:58 UTC