Wcag: 2.4.7: Focus Visible - verbiage to discourage low contrast implementations

[chlane]

As an Accessibility Engineer I am trying to prevent developers from implementing low contrast focus indication. Some developers I am trying guide are insisting that WCAG allows low contrast visual focus indication as long as it is 2px wide. They are using verbiage from G195 to support their case. More details can be found at https://github.com/w3c/wcag/issues/1586. I'm hoping to get some form of official support for my opinion that they should provide 3:1 contrast for any visual focus indication regardless of pixel width.

[mraccess77]

This should also tagged with WCAG 2.2 SC 2.4.11 as that criterion that relates to this is still in draft.

[chlane]

@mraccess77 thanks Jon, I'm trying to but it looks like I don't have the ability to add labels.

[bruce-usab]

@chlane, if you ping [email protected] , i would be happy to provide some moral suasion via email, if that would help. Or maybe it is enough to point them to this thread?

Dear colleagues of @chlane: please provide provide 3:1 contrast for any visual focus indication regardless of pixel width. This is the bare minimum regarded for something to be visible per WCAG 2.0 SC 2.4.7. In my experience, in the federal sphere, we routinely aim for 4.5:1 -- but that much contrast can be counterproductive (or even impossible) depending on what else is going on with the page.

[chlane]

@bruce-usab thank you! This thread should suffice

[alastc]

Hi @chlane,

We have some versioning going on here, where in WCAG 2.0 'focus visible' doesn't define what visibility is, so there needs to be something, but it could be anything.

In WCAG 2.1 non-text contrast was introduced, and if the indicator is around the control, it needs to contrast with the background (outside the control). There isn't a requirement to contrast with the control though.

I think that is sufficient for your case?

In WCAG 2.2 we have a potential criterion which defines the visibility, including . G195 was updated to be sufficient for the new criterion, but from the other issue we'll take a look at that if it is misunderstood. It was updated before we had the versioning in place, so we might need to update the 2.1 version separately.

[chlane]

Hi @alastc thanks I think we weren't paying enough attention to the word "adjacent". I see that we need to pay attention to where the visual focus indication is occurring i.e, inside our outside of the control and what exactly we are trying to contrast our visual focus indication technique with.

[mraccess77]

Hi @alastc you said "In WCAG 2.1 non-text contrast was introduced, and if the indicator is around the control, it needs to contrast with the background (outside the control). There isn't a requirement to contrast with the control though."

1.4.11 says "against adjacent colors" - so it would appear that this could either be the background of the page or the control itself - but doesn't require both. So I'd read it that the author can choose which to contrast with. If it must be the page background - then what happens when the focus indicator is inset and is only adjacent to the control background and not page background?

[alastc]

what happens when the focus indicator is inset and is only adjacent to the control background and not page background?

1.4.11 doesn't apply in that case. We went through that whole discussion on whether states would have to contrast with each other, and using 'adjacent' contrast doesn't work for hover types states, and is tricky to apply to focus if it is within the control.

We came to the conclusion that being able to apply it to things check marks was more important, and we didn't want to force people differentiate less important states like hover.

That's why there is a section in the understanding doc:

This Success Criterion does not require that changes in color that differentiate between states of an individual component meet the 3:1 contrast ratio when they do not appear next to each other. For example, there is not a new requirement that visited links contrast with the default color, or that mouse hover indicators contrast with the default state. However, the component must not lose contrast with the adjacent colors, and non-text indicators such as the check in a checkbox, or an arrow graphic indicating a menu is selected or open must have sufficient contrast to the adjacent colors.

That's why I'm enthusiastic for the new SC, because a comparison between states (not adjacent colours) is really important for focus styles.

[mraccess77]

Hi @alastc thank for the explanation - I am well aware that 1.4.11 does not to compare focused states and non-focused states. But I did not realize that an inset focus indicator was somehow related to that. If the working group has consensus on that -- fine - but I don't think it's an obvious fact if you are to just look at the focused state alone. The loop hole will be addressed by the proposed SC 2.4.11.

[alastc]

Hi @chlane, have the answers in this thread resolved your question now?

If pointing them to the draft of the new criteria works, that would be good to know. If they don't understand something there, please let us know and we can work on it.

[chlane]

Thanks Alistair my question was answered although it the question comes up again I will refer to the new criteria.