W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2015

Re: Poor contrast on focus indicator: SC 2.4.7 failure?

From: Gregg Vanderheiden <gregg@raisingthefloor.org>
Date: Tue, 26 May 2015 14:40:19 -0500
Cc: Sailesh Panchang <sailesh.panchang@deque.com>, IG - WAI Interest Group List list <w3c-wai-ig@w3.org>
Message-Id: <B7436B95-635D-4F24-8F7E-ED1688033EBE@raisingthefloor.org>
To: Phill Jenkins <pjenkins@us.ibm.com>
thanks

PS   Also note that WCAG only applies to TEXT and not to contrast of anything else. 

gregg

----------------------------------
Gregg Vanderheiden
gregg@raisingthefloor.org




> On May 26, 2015, at 2:30 PM, Phill Jenkins <pjenkins@us.ibm.com> wrote:
> 
> I thought I read that Gregg already answered your question: 
> 
> Gregg said: "... But we were unable to get [Poor contrast of the focus indicator ] into WCAG - partly because it was seen as a User Agent issue and partly because it can be addressed by CSS or AT — so it was not seen as an author issue.   And I had to agree — it was important but the author was not the primary place to solve it (and not the best - since it would vary from page to page if done by the author).   However, when the author did things in flash or other places where they created their own focus indicators - I’m not sure how others would know where the focus was - unless they exposed it.  So maybe “programmatically determinable” would be good." 
> 
> Since WCAG 2.4.7 is about not-hiding the focus indicator, and 1.4.3 doesn't apply to controls, strictly speaking it would "pass" the authors responsibility, but would fail the end-users needs when the browser didn't meet UAAG 1.3.1.  Although I agree it should be recommended as a best practice that icons, controls, and focus indicators should also have a default minimum contrast of 4.5 to 1 for AA conformance.  Remember it gets a little tricky, or there needs to be special consideration for disabled controls.  For example, I typically recommend a 3 to 1 contrast for disabled text on controls, and many user experience (UX) professionals do not recommend that the focus indicator even stop on disabled controls when tabbing. 
> 
> References: 
> WCAG 2.4.7 <http://www.w3.org/TR/WCAG20/#navigation-mechanisms-focus-visible> Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA)Understanding Success Criterion 2.4.7 <http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html#navigation-mechanisms> 
>         F55: Failure of Success Criteria 2.1.1, 2.4.7, and 3.2.1 due to using script to remove focus when focus is received <http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140916/F55#navigation-mechanisms> 
>         F78: Failure of Success Criterion 2.4.7 due to styling element outlines and borders in a way that removes or renders non-visible the visual focus indicator <http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140916/F78#navigation-mechanisms> 
> 
> WCAG 1.4.3 <http://www.w3.org/TR/WCAG20/#visual-audio-contrast-contrast> Contrast Minimum: The visual presentation of text <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#textdef> and images of text <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#images-of-textdef> has a contrast ratio <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#contrast-ratiodef> of at least 4.5:1. (Level AA)Understanding Success Criterion 1.4.3 <http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html#content-structure-separation> 
> 
> UAAG 1.3.1 Highlighted Items: The user can specify that the following classes be highlighted <http://www.w3.org/TR/UAAG20/#def-highlight> so that each is uniquely distinguished: (Level A)
> Selection
> Active keyboard focus <http://www.w3.org/TR/UAAG20/#def-active-input-focus> (indicated by focus cursors and/or text cursors)
> Recognized enabled input elements (distinguished from disabled elements)
> Recently visited links
> Found search results
> 
> ____________________________________________
> Regards,
> Phill Jenkins, 
> IBM Accessibility
> 
> 
> 
> From:        Sailesh Panchang <sailesh.panchang@deque.com> 
> To:        Jonathan Avila <jon.avila@ssbbartgroup.com> 
> Cc:        Gregg Vanderheiden <gregg@raisingthefloor.org>, Wayne Dick <waynedick@knowbility.org>, IG - WAI Interest Group List list <w3c-wai-ig@w3.org> 
> Date:        05/26/2015 10:49 AM 
> Subject:        Re: Poor contrast on focus indicator: SC 2.4.7 failure? 
> 
> 
> 
> Should this be documented as a failure then?
> Sailesh
> 
> 
> On 5/26/15, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote:
> >> But consider a case where the default focus indicator is passable. Now if
> >> the content author styles the background / foreground colors in a manner
> >> that introduces poor contrast and as a result, the focus indicator is no
> >> longer clear. It is not the browser's fault but a CSS / author-introduced
> >> issue. So is it alright to fail poor contrast on the focus indicator under
> >> SC 2.4.7?
> >
> > Yes definitely in my opinion.
> >
> > Jonathan
> 
Received on Tuesday, 26 May 2015 19:40:50 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 25 May 2017 01:54:15 UTC