Implement focus indication for editors and panels

[alexdima]

Testing #2145

cc @stevencl @bgashler1

Here I am tabbing into the editor from the find widget. There is no visual indication that the editor just got the focus.

@bpasero Feel free to give to me if you think I should do something inside the editor or otherwise keep it if you think the workbench should highlight somehow the title area to indicate focus.

[bpasero]

@chrisdias @stevencl fyi

[stevencl]

Thanks. We should spend some time thinking about how best to indicate that an editor has focus. I don't know yet if it should involve the title area or the editor. @bpasero - did you have any specific ideas?

[bpasero]

Not much, I guess the editor title area is a good start to add some indicator.

[bpasero]

Very related to #2500

[bpasero]

(needs UX thinking)

[bgashler1]

Summary of our meeting today with @chrisdias, @isidorn, @stevencl, @bpasero and me.

We're going to need to look into exactly what the accessibility requirements are concerning focus on Tab vs focus on mouse.

Provided these requirements are permitting, we want to first try making focus outlines only for Tab (unless a user is in high-contrast mode). We are wanting to model how Office differentiates focusing with mouse vs keyboard navigation.

@bpasero suggested making focus on mouse always go to the body after click (so no outlines will appear, whereas tab will actually focus.

A similar solution I suggested is that we could listen for the Tab key and add a .tab-focus class to a top-level parent (e.g. body) which has rules to add focus indicators globally. This class is removed immediately on any user click, and will only return again when the Tab key is pressed again.

[bpasero]

Actually what I saw happening e.g. in the boostrap theme when you click a link is that focus just moves to the body because the interaction is a real page transition, so it makes sense to move focus then.

[bpasero]

@chrisdias @bgashler1 @stevencl I think the issue exists not just for code editors. Today you can open a markdown preview, an image or even a diff of 2 images in the editor part and we are not indicating any focus there. I think in the end we need an indication in the title area of the editor and cannot just rely on the control within the editor to provide focus feedback.

[chrisdias]

👍

[bpasero]

moving to @bgashler1 to decide if the high contrast theme is good enough for this to be done. I think we agreed that we want the strong indication for accessibility only in that theme:

[chrisdias]

I was trying this today but with only one editor open and I found it difficult to know that I had even tabbed into the editor. This is a key piece of information. We have other focus highlights without the HC theme therefore I would think we need to fix this.

[bpasero]

What about adding an extra rule that only applies to the editor if it has keyboard focus and only in HC theme?

[chrisdias]

I'm not sure why we want to tie it to the HC theme. We show a nice, light focus indicator (in blue in the dark theme at least) everywhere else without the HC theme.

When i look at this I really have to study the screen to tell which editor has focus (I know which editor has focus :):

something subtle like this would be nice (picture B more than picture A):

[bgashler1]

And here are the hc-black and light themes.

[bpasero]

@bgashler1 thanks!

@chrisdias @stevencl @bgashler1 honestly I am not a big fan of adding a blue box around the editor with focus. i am also not sure if it helps a user or adds more confusion if you end up with something like this:

Given this is a sensitive change with impact, moving to post GA.

[chrisdias]

Agreed, especially on the HC theme, i can't tell what has focus in the above picture. I would love to have something more subtle near the editor title where the name is.

[bgashler1]

@bpasero: good call to delay (I don't want to break anything)

@bpasero and @chrisdias: I would love to discuss this with you all in a later UX sync. The reason I did it this way is because focus tends to show the entire bounds of what can be interacted with at the current tab position. Putting focus on the title/header of the editor may suggest that keyboard action will open the recent files palette to allow switching to a different file in that editor (after all, that's what clicking on the header does). I felt it was important for users to know that they are currently tabbed into the text-editable area of the editor (not any other part of the editor). This is also how this very editor is while I'm using it on GitHub. IMHO, If my focus were on the the header or anywhere out of bounds where I'm typing, I feel I'm interacting out of bounds or that there was a glitch.

I do agree that the high-contrast theme instance could be improved. The current line and the outline of the focused editor are indeed confusing, now that I'm looking at it again. I was trying to be consistent with focus colors on this, but I think this deserves an exception. If we continued with the editor outline approach, I think we should make the editor outline a different color and perhaps 1px instead of the current 2px size.

[bpasero]

I feel like this should be closed as we have run with this model for such a long time and adding anything to indicate focus seems like it could piss off people that liked our current model. @alexandrudima @stevencl @misolori thoughts?

If this is an accessibility issue, we can make a tweak maybe only for high contrast theme.

[miguelsolorio]

Currently tabbing away from the Find widget navigates you to other areas (panels, activity bar, etc.), but tabbing backwards will take you back to the editor (and it has focus). This works as I'd expect it.

[bpasero]

@misolori I think the concern from Alex was that jumping into the editor does not give any real focus indication (other then maybe a blinking cursor)

[miguelsolorio]

Ah, gotcha. I could maybe see us adding the focus outline on the the current line until the user starts typing. But I would still prefer how it currently works with the blinking cursor.

[bpasero]

@misolori yeah me too

[alexdima]

I don't feel passionate about this issue. It is fine for me to close it.

[bpasero]

Ok think so too, thanks.