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: Phill Jenkins <pjenkins@us.ibm.com>
Date: Tue, 26 May 2015 14:30:45 -0500
To: Sailesh Panchang <sailesh.panchang@deque.com>
Cc: WAI Interest Group List list <w3c-wai-ig@w3.org>
Message-ID: <OFE7AC215D.992E401F-ON86257E51.005A3234-86257E51.006B2FF8@us.ibm.com>
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 

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 

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

WCAG 1.4.3 Contrast Minimum: The visual presentation of text and images of 
text has a contrast ratio of at least 4.5:1. (Level AA)Understanding 
Success Criterion 1.4.3

UAAG 1.3.1 Highlighted Items: The user can specify that the following 
classes be highlighted so that each is uniquely distinguished: (Level A)
Active keyboard focus (indicated by focus cursors and/or text cursors)
Recognized enabled input elements (distinguished from disabled elements)
Recently visited links 
Found search results

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

On 5/26/15, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote:
>> But consider a case where the default focus indicator is passable. Now 
>> the content author styles the background / foreground colors in a 
>> that introduces poor contrast and as a result, the focus indicator is 
>> longer clear. It is not the browser's fault but a CSS / 
>> issue. So is it alright to fail poor contrast on the focus indicator 
>> SC 2.4.7?
> Yes definitely in my opinion.
> Jonathan
Received on Tuesday, 26 May 2015 19:31:25 UTC

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