Wcag: Focus visible not required whilst element focused

[alastc]

From Christophe Strobbe:

---

Dear AGWG,

The proposed SC 2.4.11 closes an important loophole but neither SC 2.4.7
nor the new SC 2.4.11 require that the focus indicator remains visible
until the link or UI component loses focus again. (It is technically
possible to indicate focus by means of a glow effect or another visual
effect that disappears within seconds.)

In SC 2.4.7, the following rewording would solve this:

"Any keyboard operable user interface has a mode of operation where each
UI component's keyboard focus indicator is visible until the component
loses focus."

In SC 2.4.11, the issue can be addressed by adding the following condition

• "The focus indicator remains visible until the UI component loses focus."

Alternatively, in order to avoid repetition, one might add a definition
for "keyboard focus indicator" that includes a requirement for its
visibility.

[JAWS-test]

In the Understanding it could be added that this only applies as long as the User Agent has the focus

[patrickhlauke]

Any such change should also then be made/clarified in 2.4.7.

However, from my own reading of both 2.4.7 and 2.4.11

Success Criterion 2.4.7 Focus Visible (Level A): Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

Success Criterion 2.4.11 Focus Visible (Enhanced) (Level AA): When a User Interface Component displays a visible keyboard focus, all of the following are true: ...

it does not suggest that it's required to just show a "change" in focus, but to actually show the keyboard focus, full stop. Once an element receives focus, it has focus. and under those SCs, the focus needs to be visible. I don't perceive a loophole/gap here, for once.

but sure, if it helps avoid misunderstandings, i'm all for adding a note in the understanding documents for both 2.4.7 and 2.4.11 that clarifies that focus needs to remain visible for as long as the element has focus/is focused, and give an example of something like a "yellow flash" that only shows when an element first receives focus and then fades away or similar.

[cstrobbe]

@patrickhlauke
The issue I am trying to address it that the focus remains visible, instead of being visible only for a short amount of time. Since the Understanding document is not normative, I would suggest clarifying this in the SCs or in a definition.

[patrickhlauke]

@cstrobbe i understand this, but i'm saying that i don't believe the normative wording even today allows for this sort of "focus appears briefly, then disappears" type problem.

when an element receives focus, it has focus. and the SCs require focus to be visible. (as in the SCs can't be read as "only show when focus is received", at least not to me)

[alastc]

As written, I agree with Patrick, and just note that 2.4.11 is written to build on top, the requirement is for the indicator to have certain characteristics, whereas 2.4.7 is for the mode of operation. Logically then the key place for an understanding update would be the 2.4.7 understanding.

Although (and I think this relates to another thread), allowing the vertical flashing bar in 2.4.7 is somewhere in the middle, it is not permanently visible or invisible.

[patrickhlauke]

Although (and I think this relates to another thread), allowing the vertical flashing bar in 2.4.7 is somewhere in the middle, it is not permanently visible or invisible.

complicating matters further, in some browsers/platforms you can define in settings/preferences how often/if the caret/cursor blinks and at what frequency. if it's not a completely custom one.

but this gets into even murkier territory of defining things in ever more restrictive terms (we going to define something like "over a period of X milliseconds, the focus indicator needs to visible at least X% of the time"?). taking a step back and saying, in common terms, that there's an indicator of where the current focus is, and that indicator remains present for as long as an element has focus (in a note in understanding), is sufficiently specific (unless we can back up a claim that it wouldn't be)

[awkawk]

I agree that 2.4.7 does not allow a focus indicator that isn't visible for any time the object is focused. It is worth noting that the Understanding document already says:

This Success Criterion helps anyone who relies on the keyboard to operate the page, by letting them visually determine the component on which keyboard operations will interact at any point in time.

[alastc]

@awkawk wrote:

2.4.7 does not allow a focus indicator that isn't visible for any time the object is focused

So how does that square with allowing the blinking cursor?

Or should this example from the understanding be read as a non-blinking cursor?

When text fields receive focus, a vertical bar is displayed in the field, indicating that the user can insert text, OR all of the text is highlighted, indicating that the user can type over the text.

I have to admit, I'd assumed that was the browser-default blinking cursor.

[patrickhlauke]

So how does that square with allowing the blinking cursor?

as much as i hate saying it, i think this will fall more under a "common sense" approach. default blinking cursor is still always on the focused (text) input. yes it's not "visible" every microsecond that the user may be looking at the screen, but it's constantly blinking and "present". it's unlikely that a sighted user will look at the screen, catch it just when the cursor's blink rate means it's "off" just at that particular moment in time, then look away and think "oh, there's no actual focus indication here at all".

(other options would be disallowing blinking cursors as sole visible focus indicators, which i'm not a fan of as i'd argue they're "visible" in the broad/wide sense of 2.4.7, or writing a VERY stupidly specific "it must be visible at least X% of the time in every 1 second time period" or some other pseudo-scientifically accurate calculation model)

[alastc]

Yes, I think we have to leave it as-is for 2.4.7, but it wouldn't pass the new one. Ok, thanks.

I'll propose a response (not yet agreed by the group) to the original comment that:

---

The normative wording already requires the indicator to be visible whilst an element has focus.

When we revise compile the issues for the new success criteria we will ensure the understanding document for the new SC makes it clear that a timed-out indicator would not meet the new SC.

[patrickhlauke]

it could still be noted explicitly in the non-normative understanding for 2.4.7 if that will ease any lingering concerns (even though the "at any point in time" section that @awkawk quoted covers this aspect already, it's maybe a bit implicit in what it means)

[alastc]

OK, I've added this to 2.4.7 (in a branch):
"The focus indicator must not be time limited, whilst the element has keyboard focus the indicator has to be visible."

[patrickhlauke]

This wording would imply, to me, that approaches using something like :focus-visible would now not be allowed, as regardless of how focus was set (e.g. by clicking a mouse, tapping the screen, etc) the keyboard focus (i.e. activeElement of the document) MUST now always be visible.

e.g. I click on a <button> with my mouse. the <button> now (perhaps after executing a function) has "keyboard focus". it now MUST show a visible focus indication (irrespective of the fact that I clicked it with the mouse, rather than being in a "mode of operation" of using the keyboard).

[edit: however, it can of course be argued that the whole of 2.4.7 is scoped to/includes this idea of "mode of operation". maybe that's implicit enough then that this also just applies in those circumstances. and yes, having refreshed my memory on the conversation leading up to this point, I think the above may actually be all that's needed...]

[alastc]

Ok, to leave a little room for the 'focus-visible' bit, how about:
"The focus indicator must not be time limited, when the keyboard focus is shown it must remain."

[patrickhlauke]

yup, that looks/seems ok to me, and i think it captures the essence of what was originally seen as the problem by @cstrobbe

[alastc]

Hi everyone,

We discussed this in the last meeting and the group agreed with the following response:

---

The group agrees with the comment that 2.4.7 does not suggest that it's required to just show a "change" in focus, but to actually show the keyboard focus. Whilst a change of normative text is not required, it makes sense to include an update to the understanding which says "The focus indicator must not be time limited, when the keyboard focus is shown it must remain." This will be incorporated with updates to the focus visible documentation soon.

---

Minutes, and the change is in the branch for updates to focus-visible-enh.