Consider hiding focus on certain widget types until the Tab key is used

[ecton]

Smart focus handling

This made me wonder why focus highlighting is less disturbing in other GUIs, and started looking at prior art.

I noticed that many GUIs / websites seem to render focus highlights only "on demand", which feels pretty neat. The idea is basically that the focus highlights are mostly hidden, even after clicking a button. For instance when I click the "Write" and "Preview" buttons in the GitHub text form, they don't get highlight rectangles:

Only after pressing <TAB> once the currently focused element gets revealed via the visual hint:

From there the highlights are rendered until a blur occurs, e.g. the user clicks into no man's land.

This feels pretty natural, because when switching from using the mouse for controlling the UI to the keyboard, a single <TAB> stroke is needed. Typically when navigating with the keyboard, one is used to hitting the <TAB> key frequently, so the overhead of the initial key press is negligible. At the same time, when navigating a UI purely with the mouse, one simply doesn't care about what has the focus (because it basically has no effect in pure mouse navigation). This allows to keep the "distracting" focus hints hidden by default, and only opt-in into rendering them when actually needed.

I would assume that such a smart focus handling would require a bit more work though.

Originally posted by @bluenote10 in https://github.com/khonsulabs/cushy/issues/203

After the work in #203, the main complaint of the focus indicator being too harsh has been solved, and most of the other feedback has also been addressed or already has features to allow supporting them, but this request to delay focus visualization until the tab key is used is still something to be considered. Some frameworks are implementing this approach, and we might want to consider it.

I personally think this trend isn't good for UI design because it hinders keyboard accessibility discovery. By having a focus indicator, it shows the same sort of style that text input fields always show, hinting to the user visually that a specific widget has the ability to be interacted with using the keyboard. Button-like widgets should be able to receive keyboard focus and should be able to be activated using the space bar.

There are two possible approaches for this implementation. After clicking on a button-like widget, either:

1. The widget has "phantom" focus: no indicator is shown, but pressing the space bar still activates the widget.
2. The widget does not have focus and does not respond to space bar, but the Window keeps track of the widget that was clicked so that when Tab/Shift-Tab is used, this widget is the origin of the keyboard focus rather than the first focusable widget on the window. Buttons cannot receive focus until after the Tab key has been used at least once.

In implementation 1, the user would be surprised to find out hitting the space bar activated the button, which I feel is bad design. In implementation 2, imagine a user returning putting a window in the background and returning to it later. If it shows no current keyboard focus, that user could be surprised that hitting tab started at the button rather than going to the widget that would have received focus initially when the window opened.

To me I would prefer to continue working towards making Cushy beautifully styled while preserving the focus indicators and full keyboard accessibility.

[hydra]

for what it's worth, I agree with disabling the focus ring until tab is pressed or the keyboard is used in a list. (up/down cursor keys)

Implementation idea 1 is how Windows does it, it's never been an issue for me. Remove the focus ring when the mouse is clicked anywhere in the window and show it again when the keyboard is used (e.g. up/down keys in lists, space bar on widgets, or pressing tab)

You could also make the hidden focus ring run-time or compile-time configurable too...