2.4.11 Focus Visible (Enhanced) Remove F78 and F55

[ShadowBB]

In the understanding document of the working draft:
https://www.w3.org/WAI/WCAG21/Understanding/focus-visible-enhanced.html

F78 and F55 are listed as failure techniques.

However the SC itself is only applicable if(!) there is a visible focus
"When a User Interface Component displays a visible keyboard focus, all of the following are true: "

If there isn't a visible keyboard focus (which is the case if either F78 or F55 are followed) this SC should be "not applicable", not a "failure".

[mraccess77]

I personally feel these techniques are appropriate here.

[awkawk]

Interesting observation. The SC language is causing this issue.

If a developer removes the visible focus, do we want 2.4.7 focus visible AND 2.4.11 Focus visible (enhanced) to both fail? Or do we want:

When focus is invisible/gone:
Fail 2.4.7 because the focus isn't visible
Fail 1.4.11 because the focus doesn't meet 3:1
Pass 2.4.11 because there is no visible focus, even though one is needed.

When focus is light (2.5:1):
Pass 2.4.7 because the focus is visible at all
Fail 1.4.11 because the focus doesn't meet 3:1
Fail 2.4.11 because the focus doesn't meet the enhanced criteria.

When focus is dark but doesn't change the color much from non-focus state:
Pass 2.4.7 because the focus is visible at all
Pass 1.4.11 because the focus meets 3:1
Fail 2.4.11 because the focus does not have 3:1 relative to prior appearance.

Because the SC says: "When a User Interface Component displays a visible keyboard focus, all of the following are true:" The situation where there is no focus shown at all would pass this SC. I don't think that is what we want. I think that we want:

2.4.11: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator meets all of the following: (same bullets)

This would make it crystal clear that failing 2.4.7 means failing 2.4.11.

[awkawk]

And then the techniques are unambiguously applicable. We could even get rid of 2.4.7 in WCAG 2.2! (ducks)

[alastc]

@awkawk Ha, that's where the language started, I think it was you who updated it to change from the wording of 2.4.7!

Also, I think it best to take 1.4.11 out of the equation, there is another thread/PR on that which removes the focus style examples.

It probably is worth tying into the #1050 discussion when we get to that.

[patrickhlauke]

@awkawk

I think that we want:

2.4.11: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator meets all of the following: (same bullets)

This would make it crystal clear that failing 2.4.7 means failing 2.4.11.

yup that would make the most sense to me

[awkawk]

@alastc probably, although I don't recall that...

[guyhickling]

2.4.11: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator meets all of the following:

That wording still doesn't seem to me to specifically require there to be an indicator, it still only applies if there is one. But does that matter? So long as having no focus indicator fails 2.4.7 and when there is one it must abide by 2.4.11, then we have two complementary SCs that catch either of those defects.

So why not, to put 2.4.11 as simply as possible,

Any keyboard focus indicator meets all of the following:.....

and leave it to 2.4.7 to catch the absence of an indicator. I have always mistrusted those words "has a mode of operation" wherever they have been used in the WCAG. They are not easy to understand, and consequently could allow designers and developers to come up with all kinds of loopholes (whether valid or not).

[alastc]

That wording still doesn't seem to me to specifically require there to be an indicator, it still only applies if there is one. But does that matter?

Since 2.4.7 uses that language it would, but that ends "is visible", and this ends "meets all the following". Both are saying there is one, and that hasn't been a misunderstanding in WCAG 2.0, so I think we're safe there.

See the comments at the start of the thread about why it's an issue - making the new SC be a clearly more stringent requirement than the old one.

[alastc]

The latest version (branch coming up for survey) uses the same intro as 2.4.7:
https://raw.githack.com/w3c/wcag/wcag22-focus-visible-enh-updates/understanding/22/focus-visible-enhanced.html

[mbgower]

This change was unnecessary. The two failure techniques initially cited both failed 2.4.7. There was no need to alter the definition of 2.4.11 to make them apply, because the situation was already failing WCAG. The simple answer was to remove the failure techniques from this new SC.
By altering the wording of 2.4.11, the data normalization of WCAG has been further eroded (same thing fails more than one SC) AND an unwanted phenomena that was able to 'get by' 2.4.7 through the mode of operation language but was stopped by the more encompassing language of 2.4.11 now gets the same pass.
In example, we failed to get agreement on the 2.4.7 language covering sticky footers. Since the mode phrase that was primarily cited by folks didn't exist in 2.4.11, the sticky footer had a greater chance of applying. Now, that's no longer the case.

[alastc]

Hi @mbgower,

Ok, we if we don't replicate the 2.4.7 language I'd want to be sure we're not leaving a gap.

Now we've settled the question on 2.4.7 being A and the new one being AA, I'm happy to reconsider this one so long as we don't create a gap.

So the alternative is to start the SC off with the previous text:
"When a User Interface Component receives keyboard focus, all of the following are true:"

Or perhaps something more focused on the indicator:
"For the keyboard focus indicator of each User Interface Component, all of the following are true:"

For the latter version, I think F78 would still be applicable, but F55 is about removing the focus from the element.

[mbgower]

I don't understand what the gap is. 2.4.7 requires visible focus indicator. If it isn't visible, it fails 2.4.7.
Once it is visible, it needs to meet 2.4.11. The original language (the currently published version) did not need to be changed:
"When a User Interface Component displays a visible keyboard focus, all of the following are true:

[alastc]

Hi @mbgower, I don't think we are leaving a gap, but I'm always surprised how other people manage to spot things! Anyway, it's on the survey for today.

[mbgower]

Proposed AG response:

After much discussion, the working group elected to leave the proposed language for Focus Visible (Enhanced) in place, which varies from the language for Focus Visible. As such, you are correct; failure techniques F78 and F55 should not apply to the new enhanced SC. If there is no focus indicator, they would instead fail the existing Focus Visible SC.
We will remove the two failure techniques from Focus Visible (Enhanced).
We will add an addition to the Understanding document stating something like:
' Focus Visible (Enhanced) is designed to set criteria for the level of visibility of an existing focus indicator. If the author does not offer any visible focus indicator when a component receives focus, the content would instead fail 2.4.7 Focus Visible. '

[alastc]

The group agreed with the response above:
https://www.w3.org/2020/07/21-ag-minutes.html#item07
Closing the issue