Similar to Alt providing users access to the menubar, when the menubar is hidden in the tabbed Notebookbar, Alt could provide access to the Notebookbar tabs.
Yes, but rather than <Alt> mod-key accelerators, some could/should be provided as short-cuts.
By default the ALT focus (Alt + F for menubar file) is on the menubar, in notebookbars you can turn off the menubar and it would be very usefull that - if menubar is turn off - the focus will move to Notebookbar. If the menubar is on than the ALT focus is at menubar.
*** Bug 156895 has been marked as a duplicate of this bug. ***
*** Bug 170293 has been marked as a duplicate of this bug. ***
(In reply to V Stuart Foote from bug #170293 comment #1) > LibreOffice does not implement the Windows Ribbon API to create its MUFFIN > Notebookbar (NB) "Tabbed" UI. > > Accessibility and keyboard navigation is already well addressed with > consistent keyboard controls. That is keyboard movement onto the NB's UI > elements is via an normalized <F6> focus event onto the NB, the active "Tab" > will highlight. While using <Ctrl>+<Tab> or <Ctrl>+<Shift>+<Tab> (or the > cursor keys) keyboard actions to advance between NB tabs. > > Once focused into a NB assemblage of controls, keyboard movement is only by > <Tab> or <Shift>+<Tab> to move between controls. > > Use <F6>/<Shift>+<F6> will advance focus between UI elements. And when Main > menu is exposed (it is hidden by default, but exposure button is provided in > each NB assemblage) an <F10> will focus onto main menu. With <F6> available > to move between UI regions. > > The <Alt> key then will expose the mnemonic accelerators of the menu > controls and functions in those keyboard sequences. > > As should be obvious, in that context the <Alt> key is already allocated and > is not available to further overload for movement onto the NB Tabbed > assemblages--just for the Windows builds. The LibreOffice Notebookbar is not > the MS Ribbon API. > > IMHO => WF I understand that we are not using the Windows Ribbon API and that Alt is reserved for menu accelerators. However, relying on F6 loops is a significant accessibility barrier (WCAG guidelines usually discourage cyclic navigation for primary toolbars). Proposed Technical Pathway: Could we introduce a ProcessKey intercept in the Notebookbar controller? If the Notebookbar is the active UI mode: Detect the standalone KEY_MOD1 (Alt) event. Suppress the default MenuBar activation. Instead, call GrabFocus() on the active Tab control of the Notebookbar. This wouldn't require implementing the full Windows API, but simply re-routing the focus event in this specific UI context to match the Universal Accessibility expectation for tabbed interfaces."