Pressing Alt+F1 starts the key navigation mode on the launcher.
But, the object that has the focus is not the Launcher. As far as I see it is the BaseWindow containing the Launcher the one that receives the focus. At least, the BaseWindow is the one that emit the signal InputArea::OnStartFocus (when the key nav starts) and the signal InputArea::OnEndFocus (when the base window lose the focus, ie, key nav stops after press Esc).
In my opinion this is somewhat confusing, as in the end it is the Launcher that it is managing the effect of pressing a key (ie Launcher::RecvKeyPressed).
I made some experiments (on this branch [1]) trying to solve it by calling by hand InputArea::ForceStartFocus but that doesn't work. Anyway, after review the implementation of this I'm not sure if it is correctly implemented as it ends calling the method m_EventHandler.ForceMouseFocus (x, y, m_Geometry), when I want a key focus.
From the POV of accessibility, this is a case where it would be more convenient to have the focus on the Launcher, as it would be the one that in the end will implement the selection stuff for each icon.
[1] https://code.launchpad.net/~apinheiro/unity/focus-on-launcher
I implemented the following call in BaseWindow:
void SetEnterFocusIn
What this does is set an input area (such as the Launcher) as the view that receives the keyboard focus when the BaseWindow responds to the event NUX_WINDOW_
When Alt+F1 is activated, we raise the position of the Launcher's BaseWindow to the top of the BaseWindow stack. That way, our Launcher BaseWindow is the first (and only one) to process the NUX_WINDOW_
If an input area was set with SetEnterFocusIn