Re: Focus visible test page

Hi Andrew,

Thanks, holiday was good, just getting brain back up to speed again!


> Just FYI the buttons are not functional using Safari, though the form fields are. In Safari the form fields all have the “autofill” clickable focus indicator from the user agent.

I put the page together whilst at home (on Windows), so I hadn’t spotted the outline on the last few buttons.
None of them are supposed to ‘function’ as such, just be tab-able.

I also don’t get the autofill indicator in any browser, might that be a plugin you have? The inputs are the simplest markup, e.g. <input type="text" class="example12" id="example12">
So any autofill is coming from the browser.


> Both of these issues indicate problems with focus related to user agents… I don’t know if this could be part of the SC, a blurb about this issue, encouraging testing on all browser types might be good to have in the understanding section.

That’s fair. It wouldn’t be part of the SC as it is not in the authors control, but I think it could be phrased as something like “there may be other indicators added by user-agents which may impact focus visibility, but these are not part of the SC.


> A general conclusion is that … it is font stroke width (weight) and not font size per se that determines where it fits on the CSF curve…. This directly applies to the width of any border. Thinner borders (1px) need more contrast than thicker borders for the same contrast perception.

Ok, understood (I think), but it’s a matter of having a metric to capture that.


> On the test page, a BG of #EEE and a 1px border of #333 is a WCAG contrast of nearly 11:1, that’s far more than the SC’s requirement of 3:1 (#888) as I understand it?

That’s a good point, I’ll add some ‘minimum’ examples as well. Would it make a difference if the component border were at the minimum level as well? I.e. if the focus outline is at 3:1, should the initial border be at 3:1 as well to make it the worst case? I’ll try both! Examples 2b & 2c added.


> a 3:1 contrast it may not be enough. Regarding that unrelated SC we discussed for smaller thin fonts (with a 1px stroke width in body text) I am looking at 9:1 to 11:1 to be appropriate contrast levels. I don’t think that much contrast is needed here, but I’m also not sure that 3:1 is enough for a 1px border - on the other hand, 3:1 is certainly enough for a 4px border…

Ok, so my understanding is that there is a balance between high-contrast + thin, and low contrast + thick, and rather than forcing a thick border (current SC text) it would be better to ramp up the contrast for thin?


> This relates to the effect spatial frequency has on perception & contrast. FWIW spatial frequency is playing a bigger role in research (not just mine) and future standards development.

Could you define spacial frequency? I looked up your github comments and found:
https://github.com/w3c/wcag/issues/635#issuecomment-514819026


I understand frequency would mean how often something appears, but how does it relate to whether something is thick / thin?

The graphic has thick & spaced out bars graduating to thin and not-spaced out bars, but what if you have something 5 units wide and 5 units spaced, or 5 units wide and 2 units spaced, or 2 units wide etc? What is the ‘spacial frequency’ of each?

  1.  |_____|     |_____|     |_____|


  1.  |_____|  |_____|  |_____|


  1.  |__|     |__|     |__|


  1.  |__|  |__|  |__|

(If that doesn’t come out properly, (1) is 5 units wide, 5 units spaced. (2) is 5 units wide, 2 units spaced. (3) is 2 units wide, 5 units spaced, and (4) is 2 by 2.)


> So the fact that the 1px add-on does not contrast with the 1px unfocused border is not relevant BECAUSE the add-on literally DOUBLES the thickness of the border overall which has a substantial effect on contrast.

I’m not convinced by this in the context of a focus indicator, I think there is a difference between:

  *   How easy is it to discern that button, now that it has a 2px border.
  *   How easy is it to discern the change, i.e. the focus indicator.

I’m not disagreeing with your point as such, but I want to check you are considering that it needs to be discerning the change rather the discerning the thing.


> I’d suggest that the added border does not need to contrast with the existing border IF it makes the existing border wider-enough (as a percentage??) that focus is perceptually clear.

Interesting. The current SC text asks for a change relative to the size of the component, e.g. a 100px by 50px button has 5000px, the 100px border would be 2% of the overall pixels. For the best cases (adding a border where there was none), I think that is reasonable.

What we are looking at is the case of adding an indicator which does not contrast with the adjacent component color. The current SC text then specified it should be at least 2px. What would a good alternative be?

If the focus indication area is adjacent to a color with which it does not have a 3:1 contrast ratio difference…

  *   The color change should be at least 4.5:1
  *   The color change should be at least 7:1
  *   The thickness should be x% of the component size…

I’m struggling to see a good metric across controls that may or may not have a border.


> Example 3: Without correction I can see no difference or focus.

Agree, that should be a fail case (it is currently).


> Example 13: I find this hard to call “contrasts with both element and BG” because it really doesn’t - it is close enough to BG that the effect is simply making the element smaller.

Yea, it doesn’t look that good to me either. The colors (#fff / #767676 / #000) do all meet 4.5:1 with each other though.
Under the current text a 1px version would fail, the 2px one just passes.


> Example 14: 14b is the best, this is echoing my comments on example 2 above. Next best is 14a which is called a fail. 14d is weakest, and weaker than 14a.

Ok, so 14b (a 1px border with 2px outline) is good, but comparing to the new example 9b (solid dark component with 2px dard outline), it is the same outline being added but I don’t think it works as well for the reasons you described. How can we adjust the metric to take that into account?


> Example 15: b c and d are not overriding the USER AGENT defaults in Chrome, and I notice the user agent obliterates nearly all of the examples on the page (with the default user agent being easier to see.)

I didn’t get that on windows, sorry, I’ve updated it. I’m not sure what you mean about the others though?

Cheers,

-Alastair