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

Poor contrast of the focus indicator was a pet peeve of mine.  

But we were unable to get it 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. 



Wayne - I saw that you also proposed some new “failures” as a way to add new regulations without changing WCAG.   a couple comments on that   ( that also apply here.)
Failures don’t work that way.  You can’t document a failure that isnt already a failure.  Failures do not create anything new — they just document things that already fail,  and document them in a way that is easy to see for those who don’t see it.
508 has no failure provisions.  Only requirements.
Any new provision in WCAG has to apply to all content - not just document-like content.  And all  parts of the content (including tables etc which you point out)  can’t reflow. 


HOWEVER
although WCAG is core to 508 — it is NOT the only requirements in 508.
you can petition that other things be required IN ADDITION to WCAG without changing WCAG.  (there are already a number of things in addition). 

If you DO ask for a new rule/ reg / provision ...
be sure you make it only apply to the type of things that it can and should apply to
for example   
"Running text in documents meant to be read in a linear flowing fashion must/shall…
"Document viewers must/shall wrap text that is meant to be read in a linear flowing fashion
try to get it focused on only the most important content types 
e.g. horizontal scrolling to see all the tabs at the top of the page is a pain, and inefficient, but  this is not critical - and it may even be easier to understand than wrapped tabs (Because they might then look hierarchical — and would be a mess if they were  hierarchical in the first place) 
however, horizontal scrolling for running text in a paragraph is almost unusable (and completely unusable to some )
so focus on the things that are really important - and avoid things that could be argued. 


So for your other provisions - and for focus indicator here - you might push for what you think is most important and most achievable and make sure you scope it so that you don’t accidentally write something that can loop in something you don’t intend - or that will raise opposition with an argument that is good.   At this late date - the only thing that has a chance - is something that is based off of things that are in the doc and that have strong support and weak opposition (or at least opposition with weak arguments  — hence the suggestion to make sure it doesn’t accidentally look like it applies somewhere it shouldn’t or can’t or would be very difficult or unreasonable to do).



Good luck    

gregg

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




> On May 24, 2015, at 6:49 AM, Sailesh Panchang <sailesh.panchang@deque.com> wrote:
> 
> Hello Wayne,
> SC 1.4.3 (AA)  applies to text and images of text and not to the
> visual focus indicator for links / other UI controls.
> Yet, poor contrast of the visual focus indicator too may make the
> focus indicator not "visible" or clearly discernible and cause a
> failure of SC 2.4.7 in my opinion.
> Do you agree / perceive poor contrast of the focus indicator as an SC
> 2.4.7 failure?
> By the way, disabling CSS may make the focus indicator visible for
> reasons not impacted by poor contrast too, yet SC 2.4.7 is on the
> books  at Level AA.
> So I do not think disabling CSS  to do away with poor contrast on the
> focus indicator will make it pass 2.4.7.
> 
> Thanks,
> Sailesh Panchang
>