- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Wed, 27 May 2015 15:43:35 -0400
- To: Gregg Vanderheiden <gregg@raisingthefloor.org>
- Cc: Phill Jenkins <pjenkins@us.ibm.com>, IG - WAI Interest Group List list <w3c-wai-ig@w3.org>
Phil, Thanks for pointing to "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" It does record this sort of failure in example 3 and perhaps 2. It does describe a "failure condition that occurs when the user agent's default visual indication of keyboard focus is turned off or rendered non-visible by other styling on the page without providing an author-supplied visual focus indicator" Also refer to the statement that reads, "..."or thick borders that are the same color as the focus indicator so it cannot be seen against them"." Thanks, Sailesh On 5/26/15, Gregg Vanderheiden <gregg@raisingthefloor.org> wrote: > 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 Wednesday, 27 May 2015 19:44:05 UTC