Feedback on Focus Visible (Enhanced): Too Much Math

[scsporie]

I am very happy to see the additional definition around Focus Visible, and support the intent of the new enhanced criterion. However, my initial reaction to the minimum area requirement is "too much math." I feel this SC will be difficult to communicate clearly to product teams and introduces a lot of complexity when testing user interfaces.

I did read the part of the Understanding page that states "If you need to use complex mathematics to work out if a focus indicator is large enough, it is probably a sign that you should use a larger and proportional indicator that will provide a more visible indicator," and I agree with that too, but that only helps whoever is defining the focus style. The rest of us are likely stuck doing the math to determine if we can classify this as a "must change to meet WCAG 2.2 AA" or "should change because the user experience is not great." I wish this distinction wasn't important, but in my experience it is to some audiences.

[guyhickling]

Stacy, I agree, its much too complicated. And that isn't the only issue with this SC - the whole thing is extremely difficult to understand. I've just raised a new issue here on GitHub about it, #1055, listing several things that I think are worded too obscurely to mean anything to anyone!

In two of the questions I raised about it I've had to offer two alternatives because I didn't know what it was saying. I read the SC, and thought I understood it. Then read the Understanding doc and realised I'd got it wrong. Read the Understanding several times more, and decided maybe I was right the first time. In the end I couldn't figure out what it was saying so on those two points (whether the first and third checkpoints apply to colour change indicators), I had to offer two alternative wordings to allow for both possibilities. Not the most easily understandable SC around!

But so far as your maths objection is concerned, I would much rather see a much simpler SC, something along the lines of (this is only very approximate wording since it isn't going to happen unfortunately) "outline or line indicators must be 2 CSS pixels or more in thickness". Simple as that. Regardless of whether its inside the component boundary or outside it. If the developer wants to make it longer than the component (by having it outside the component boundary) fine - but it still needs to be 2 - 4 pixels to make it easily visible!

Is that too much of an ask for us to expect? What designers and everybody else forget is that keyboard focus outlines don't spoil the design. No one ever sees them. Except keyboard users - and they are the very people who want a highly visible focus indicator. Mouse users can, and usually do, have a different indicator, so designers really don't need to worry about spoiling their precious designs for the sake of a few keyboard users! They won't.

So I agree your objection to the complicated maths. The thought that one day I might be having to argue with developers who are digging in their heels because they've decided to use this as a loophole, and then I'll have to do the maths as well, gives me the shivers just to think about it.

[JAWS-test]

outline or line indicators must be 2 CSS pixels or more in thickness

However, this definition leaves open how long an outline must be:

• At least as long as the element
• or on all four sides of the element
• or without length specification (then 1 x 2 px would be allowed)

[alastc]

Hi @scsporie,

Thanks for the comments, and I appreciate how complex it appears. Could I follow up to test some directions?

The core conundrum is that what makes a visible focus indicator is not particularly straightforward.

Well, it is easy to say what isn't visible, and it is easy to say what definitely would be visible, but there is a lot of grey area where, depending on how you define it, some visible indicators would be banned, and some not so visible ones would pass.

For example, adding a 1px black line around a black button is very hard to see. But if you separate it by 1px, it gets much easier. If you use a striking hue (e.g. red) as an outline, that seems easy but actually might not have much contrast for certain types of vision.

From a fair bit of testing, the key factors are:

• How much changes. I.e. the area of change.
• How visible that change is, i.e. the contrast of the change.
• How different that is from the adjacent colours.

Any one of those things is not enough, you need all three.

For common focus indicators you don't need to do any maths. E.g. if an outline is 2px thick and the change of contrast meets 3:1, that's it, job done.

Would it help to start the understanding document with an example like that?

@guyhickling wrote:

I would much rather see a much simpler SC, something along the lines of (this is only very approximate wording since it isn't going to happen unfortunately) "outline or line indicators must be 2 CSS pixels or more in thickness".

I'd love to know what you think that wouldn't happen? Do you think we'd get lots of push-back on a very deterministic requirement? (I would agree.)

Also, as @JAWS-test pointed out, someone could then make a 2x2px indicator as well.

No one ever sees them. Except keyboard users

I wish that were the case, but until the focus-visible pseudo selector is better supported (and used) people clicking on links/buttons do see them.

[guyhickling]

you think that wouldn't happen

When I said that it was because I thought the basic form of the new SC was pretty well decided (now that it is in the Editor's Draft). I hadn't realised it was still up for full discussion. Since it apparently is still open to change, could we try to find something that is really simple. a) Because too many people have already complained about how complex it is, b) because even the people involved in these GitHub discussions have completely misunderstood the present version, and c) because if we can't understand it I'm sure the outside world will have the greatest difficulty with it when 2.2 becomes a recommendation!

• I think it's reasonable to specify that any focus line or outline should be at least 2px thick as a minimum (but I think we could promote 3 or 4px as good practice).

• I also think it is reasonable to ask that any outline should be outside the button or other component, not inside it (outlines inside it are very difficult to see).

• And if it is just a single line instead of an outline then it's also reasonable to ask that it be at least as long as the component.

If we just say that, then it gets rid of the whole business of minimum areas and calculations and numbers of pixels and loss of hair/early trip to the grave!

[guyhickling]

As for push-back, I think there will be far less push-back if we keep it very simple. More than a half of all websites already use the outline outside of a component as their focus indicator of choice, so I don't think there is likely to be much complaining, provided whatever the SC says it is simple enough to understand. Most website owners just want to comply and do the right thing, just so long as they can understand what the right thing is!

[alastc]

So you'd ban things like colour reversals? (Example 6), or adding internal and very obvious blocks of colour?

Also, there are some advantages to using an internal outline:

• You can use the same type of button and outline on different backgrounds, and
• The bottom part doesn't get cut off by the edge of the viewport as you tab down a page.

Anyway, I'll review your other issue with all the updates, that's probably a better place for this discussion.

[guyhickling]

No, I'm quite happy with colour reversals and blocks of colour (but worded simply and clearly of course). It's just the outline/line type of that seems to be giving rise to so much difficulty in the new SC, because of the complicated ways of calculating it.

But I would like to stop outlines inside the button or component on principle - they are very difficult to see. Partly because there is no "structural" change to the size of the component, and partly because they usually touch the border all round (some are actually superimposed on the border which is even more difficult to see), and they are often dotted as well. Some designers even put outlines inside a tiny radio button or checkbox -that's just plain stupid to my mind, they are virtually invisible for anyone like me without 20/20 vision!

[alastc]

But I would like to stop outlines inside the button or component on principle - they are very difficult to see.

I'm struggling with this one. I ageed that things like the default FF button indicator (a tiny dotted line) are hard to see.

However, examples I've seen that meet the criteria worked well on principle and in some brief testing, e.g:

It also prevents the outline being cut-off by the viewport when your tabbing scrolls the page down.

It also allows you to have a focus style for a component / button that works across various backgrounds.

Do you have any examples that would meet the criteria but do not appear to be visible?

[guyhickling]

Yes, but don't say "do not appear to be visible". I'm not saying they are invisible, only that such outlines inside the borders of components are often very difficult to see for people who have poor eyesight of one sort or another, and this makes finding the focus very difficult, for those people, when it is potentially jumping all over a page. So I don't know how good your eyes are, but here are two examples.

1) PianoStreet at https://www.pianostreet.com/smf/index.php?topic=36281.0 This uses the browser default indicator, but is quite good for demonstrating the point. On the Print button halfway down the page, the dotted focus indicator outside the button (in Firefox) that fails contrast against the button border, is actually more visible to me than the indicator inside the 3 other buttons on the page (also dotted) which passes contrast, because the outline is outside the Print button so makes it look a bigger size on focus! (The round corners on the Print button help in this of course in this particular case.)

(And by the way, looking at that site in Chrome also confirms why browser default outlines must not be allowed - the blue Chrome outline is almost invisible against the mid-grey page background! In a custom indicator the developer can adjust the indicator colour when on similar backgrounds.)

2) On this page of the New York Times https://myaccount.nytimes.com/get-started/auth?OC=20000215760&campaignId=797YR, the dotted focus indicator inside the black Continue button, in Firefox, is very difficult to see although it has excellent contrast of 5.35 to 1. Again I'm not saying it can't be seen, only that it is very much more difficult for many people like me with poor eyesight.

[alastc]

PianoStreet: These all appear to be browser default, in Firefox that means 'dotted', so each length = 0.5 of a solid line, therefore does not pass the area requirement.

In Chrome they are all blue outlines, so different ones fail in different ways on those backgrounds.

If you play with various options, I think you'll find that if it meets the area criteria and both contrast criteria, it doesn't matter if it is internal or external. It is the amount of change that is key.

Some are better than others, but it does catch the most egregious examples (apart from some very tricksy examples recently pointed out).

[alastc]

For anyone in the working group, there are some more proposals on the table: https://www.w3.org/2002/09/wbs/35422/focus-visible-enh-issues1/

For anyone following along, the outline of those proposals is: https://docs.google.com/document/d/1F83m-HXRkXz1QCF6_QNtQGzIULugMiFSLgtqDRgKA-s/edit#

[alastc]

Hi everyone,

This was discussed at the AG meeting on Tuesday, and the general consensus was to keep some flexibility rather than prescribing a particular focus style/approach.

I''ve made some updates in a branch, the understanding doc (including SC text) can be previewed.

It would be very helpful to know if this helps with the 'too much math' problem.

Kind regards,

Alastair

[detlevhfischer]

I think this could work - I still have a slight issue with the Focus contrast bit "with the colors changed from the unfocused control". If on focus, you add an outline around a button, will people understand that the part of the background that is now covered by the outline is the colour 'changed from the unfocused control'? Because they may consider the background as being outside the control (especially when the outline is offset by a few px).

[jake-abma]

I see you removed the yellow squares example as these won't pass anymore. This also means all the other examples with a (most of the time 8 px) left border will not be allowed anymore.

Example can be seen at: https://adrianroselli.com/ the "blog" drop down, as previously shown / used as an example.

Also my examples where this interactive element becomes wider on mobile with such an indicator will not be allowed anymore.

https://codepen.io/JakeAbma/pen/rNaggxZ https://codepen.io/JakeAbma/full/rNaggxZ

This will be pretty prescriptive and probably gets pushback if at AA, so we need to be sure we want these patterns to be forbidden in future WCAG versions.

Op wo 6 mei 2020 om 17:43 schreef Detlev Fischer notifications@github.com:

I think this could work - I still have a slight issue with the Focus contrast bit "with the colors changed from the unfocused control". If on focus, you add an outline around a button, will people understand that the part of the background that is now covered by the outline is the colour 'changed from the unfocused control'? Because they may consider the background as being outside the control (especially when the outline is offset by a few px).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/1053#issuecomment-624726485, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQWTAQADAZZXZHIKVEY5MLRQGAQPANCNFSM4K5BHQJQ .

[scha14]

@detlevhfischer the SC and understanding doc regarding color contrast and adjacent color requirements are also being discussed in https://github.com/w3c/wcag/issues/1156. According to the understanding document :

When a component changes to include a focus indicator, that change can always be measured as a change of color contrast. For example, if a yellow outline is added to a button on a blue background, the change of color is from blue to yellow.

The proposed response to this aspect of the issue is encapsulated in this https://github.com/w3c/wcag/issues/1156#issuecomment-657546392

@scsporie, does the updated draft - option 3 of the SC simplify and address the too much Math concern?

[detlevhfischer]

@scha14 ok, maybe it‘s a non-issue. I have lost track, there gave been many changes to the text.

[scsporie]

The updated wording is simpler and easier to understand. The math problem still remains on the testing side - if you are trying to prove whether a non-standard focus style is sufficient or not. But on reflection, I suppose that inevitable as long as there's a minimum area requirement.

[scha14]

Thank you @detlevhfischer!

@scsporie is this okay to close?

[scsporie]

Yes, this can be closed.