Quick input: consider to better indicate list focus

[Tyriar]

#93641

Version: 1.44.0-insider (user setup)
Commit: d7d1147
Date: 2020-03-31T08:23:56.446Z
Electron: 7.1.11
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.18362

---

Using NVDA:

1. ctrl+p
2. 'term ' (announced: 2 results)
3. Press down (announced: term list, 1.1 node, ...)
4. Press tab (silence)
5. Press tab, the icon is selected (toolbar, rename terminal button, ...)

[Tyriar]

The same happens with other quick picks too like go to file.

[isidorn]

I can reproduce this, and we are doing everything correct here imho just NVDA decides not to read anything. VoiceOver behaves correctly.
Idealy the first tab would focus imedaly on the icon, not sure if that is possible though.

[Tyriar]

@isidorn what does voiceover do at step 4?

[chrmarti]

The first tab focuses on the list. My understanding is that that is how it should be from an accessibility point of view. @isidorn ?

[bpasero]

I am not seeing an immediate issue here to fix and this is pending answer from a18y experts, so moving to April.

[Tyriar]

Someone else created an issue about this the same day but from the angle that it doesn't show a focus indicator #93907, we should either remove the ability to tab to the list or if that's not good from a a11y perspective we should add a special focus indicator to it (an outline around the selected item?).

[moshfeu]

I'm voting for outline ☝️

[chrmarti]

The list does shows an outline when it has focus and there is no item focused. We usually focus an item. That's the List's built-in behavior.

[Tyriar]

@chrmarti there is no visual difference between implied focus because the textbox is focused:

and actual focus when you tab:

I think the second one should look like this or something similar:

[chrmarti]

That's on purpose, by default the implied focus looks different, but because you can navigate the list with up-/down-arrows, the implied focus was changed to look the same as the focus.

Not sure what the original discussion around this was, but this makes sense to me.

[Tyriar]

@chrmarti to me it feels broken when you transition to this:

Because you lose the "real" focus indicator, combine that with NVDA not announcing anything and it felt very broken.

[chrmarti]

The screenreader should already have read out the entry at that point, so it does not repeat it, I assume.

We are using aria-activedescendant to get the entry read out while the input box has focus, not sure if and how we could get screenreaders to read the entry again when the focus moves to the list.

[bpasero]

I find the outline around the list item a bit weird because we do not have this kind of styling in any other list or tree widget. We typically distinguish focus via the selection color:

vs

If we have to introduce an outline I would probably rather expect that to be around the entire list widget, same as we have it when no item is selected on lists:

[Tyriar]

@bpasero well the problem is we use implicit/linked focus in the quick pick but style it the same as regular focus. I still think the outline would be good because it's clear what is actually focused and this is mainly only exposed for accessibility reasons, we have also established outline to mean focus (in addition to solid bg).

Outline around textbox = textbox is focused:

Outline around close button = close button is focused:

No outline = textbox is no longer focused 🤷

[Tyriar]

cc @misolori

[miguelsolorio]

Related to this is how our list focus/active selection can be confusing:

[Tyriar]

What if multi-select leveraged the same border style I'm proposed, making it a more common paradigm to have a "higher priority" focus indicator to clear up ambiguities like this.

Shift+click:

Ctrl+click:

[bpasero]

That would be a model as Windows has it imho:

I somewhat like it but would need to try it out to provide more feedback. This would requires changes to the tree/list rendering.

//cc @joaomoreno

[joaomoreno]

I like it!

[Tyriar]

Moved explorer request to #95768

[bpasero]

@Tyriar this is not explorer specific? this applies to every list and tree?

[Tyriar]

@bpasero I think the implicit focus when textbox is focused is a quick pick thing?

[bpasero]

@Tyriar yeah, I was referring to #95768 but I think Joao already made clear that such a change impacts every tree/list usage outside of maybe quick pick.

Still, for quick pick I would want to wait for the result of #95768 to see if we can benefit from the focus ring also for quick pick. Maybe we could still align the visuals for quick pick and other lists/trees.

[TylerLeonhardt]

Looks like we have this now (following the original steps)

and hitting tab: