RE: SC 1.4.11

(Chair hat off and trying to avoid previous points<https://www.w3.org/2002/09/wbs/35422/non-text-contrast-exception-scope/>)



Patrick wrote:

>  sites that *don't* set explicit focus styles and rely on browsers are, essentially, offloading that particular behavior to browsers, and that that's not an ideal state of affairs.



It’s not ideal because (some) browsers aren't doing a very good job.



Taking John's example, in Firefox (windows) it dynamically changes the focus indicator to white for the dark background:

[cid:image003.png@01D408F8.BF41D020]



I’d rather that was thicker, but that browser meets the guideline, whereas others don’t.

This kind of dynamic behaviour takes it away from the foreground/background examples from text, as it isn’t defined by the foreground but part of the browser’s interface. A mushy middle that is over-ridable by the author.



There are bugs for this on some browsers already: https://bugzilla.mozilla.org/show_bug.cgi?id=1284235


An effect of mandating people define focus styles (in effect what John is saying) is that there is no point in the browsers improving this obvious issue.





> In fact, I later remembered this issue I filed against WCAG 2.0 … and note Alastair's comment that this would in fact be addressed by the new SC



And it is, the question is how people interpret the exception for default focus indicators:

“or where the appearance of the component is determined by the user agent and not modified by the author;”



Patrick, you’re relatively fresh to this, with your developer hat on would think that meant just the outline (for HTML/CSS), or include the background of the component, including the page?



To take that to a not- extreme example, this page passes:

https://alastairc.ac/tests/wcag21-examples/focus/example1.html


This page fails with the wider scope of interpretation:

https://alastairc.ac/tests/wcag21-examples/focus/example2.html




The difference? body{background-color: white;}



In an earlier version of the SC text this aspect was more clear cut:

https://www.w3.org/TR/2017/WD-WCAG21-20170912/#user-interface-component-contrast-minimum




After combining the two SCs there was a difference in the exception, which is why we are discussing it now.



When Glenda and I were working on this (and others, but I’m thinking of our conversations) we both read the same wording in a slightly different way and didn’t realise at the time.





John wrote:

> I would like to see the *interpretation* for this SC unambiguously state that you need to test for all possible browsers



That adds a *lot* for this SC, as the same browser on different platforms act differently! Firefox will often pass on windows, Safari will fail on any light background, as a tester you’d need at least a Windows and Mac to test on. We have generally avoided user-agent dependant results, it adds a large overhead.



Also consider platforms which have a fixed focus indicator (Andrew mentioned that on the call), if the author can change the background but not focus indicator, you would be banning a range of colours for the site. E.g. a platform with a yellow focus indicator could the not use light backgrounds.



Overall, it’s worth looking at the updated Understanding doc:

https://rawgit.com/w3c/wcag/understanding-non-text-contrast-udpates1/understanding/21/non-text-contrast.html




The top  examples are all author controlled and easily pass. There is one example that discusses default focus style in the table, but I think the weight of it is for good practice.



Cheers,



-Alastair



Also, I feel I should point out that literally (traditional meaning) the first exercise I get people to do in training is to use their site / app with the keyboard. Visible focus is important, and they will generally want to improve it.