Description: You usually can use the TAB key on the keyboard to jump from one control set to another without using the mouse. In the dialogs that use vertical tabs, the TAB key does not jump back to the tab list, so you cannot change tabs with the keyboard. Steps to Reproduce: 1. Open or create a Writer document. 2. Open the styles side-panel 3. Right-click on any style and select Edit Style... 4. Use the TAB key to jump from control to control. Actual Results: You cannot reach to focus on the vertical tab list by using only the TAB key. Expected Results: When cycling through the controls, you must eventually come back to the tab list. Reproducible: Always User Profile Reset: No Additional Info: Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: bc58a54d513702bc07906627dce073f05d7978fd CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: ro-RO (ro_RO); UI: en-US Calc: CL threaded
I think this is basically a duplicated of bug 167125
(In reply to Mihai Vasiliu from comment #0) > Actual Results: > You cannot reach to focus on the vertical tab list by using only the TAB key. > > Expected Results: > When cycling through the controls, you must eventually come back to the tab > list. That seems to work for me. Pressing Tab when focus is on the "Cancel" button moves focus to the tab list. (That focus state is not particularly well visible in my Windows 11 VM with light them, though.) Where does focus jump for you after the "Cancel" button? (In reply to Xisco Faulí from comment #1) > I think this is basically a duplicated of bug 167125 I'd suggest to keep these separate. This report here is about the basic feature of just using Tab, tdf#167125 is about providing additional ways to switch between tabs. Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: bc58a54d513702bc07906627dce073f05d7978fd CPU threads: 12; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (en_DE); UI: en-US Calc: threaded
(In reply to Michael Weghorn from comment #2) > [...](That focus state is not particularly well > visible in my Windows 11 VM with light them, though.) ... light **theme** ...
> > That seems to work for me. Pressing Tab when focus is on the "Cancel" button > moves focus to the tab list. (That focus state is not particularly well > visible in my Windows 11 VM with light them, though.) > > Where does focus jump for you after the "Cancel" button? > I took a better look and you are right, after the Cancel button if I press TAB again, the focus does jump visually to the OK button. I have no indication that it jumped on the vertical-tab area, but if I use the arrow keys to move, the focus does move to the next tab, and it is NOT actually on the OK button. The visual issue is that after the focus being on the Cancel button, pressing TAB will highlight the OK button (See the attached screenshot), but in reality the first tab is in focus. So this is like a dual-focus visual indicator issue where both the first tab and the OK button are marked as in-focus, but actually only the tab is.
Created attachment 201629 [details] Focus on both OK and tab
(In reply to Mihai Vasiliu from comment #4) > I took a better look and you are right, after the Cancel button if I press > TAB again, the focus does jump visually to the OK button. I have no > indication that it jumped on the vertical-tab area, but if I use the arrow > keys to move, the focus does move to the next tab, and it is NOT actually on > the OK button. > > The visual issue is that after the focus being on the Cancel button, > pressing TAB will highlight the OK button (See the attached screenshot), but > in reality the first tab is in focus. > > So this is like a dual-focus visual indicator issue where both the first tab > and the OK button are marked as in-focus, but actually only the tab is. The "OK" button indicator might be there to indicate that if you press Enter, that's the button/action that will be triggered, and is likely always there unless a particular other button currently has focus. Does that match what you're seeing? If so, I think that state of "two indicators" is likely intended in general (which doesn't say it's perfect or couldn't be improved, but that might be worth a separate discussion).
> Does that match > what you're seeing? If so, I think that state of "two indicators" is likely > intended in general (which doesn't say it's perfect or couldn't be improved, > but that might be worth a separate discussion). Yes! That's what I am seeing. Taking a very close look, I can see that when a button is in focus, its control text is surrounded by a thin black dahsed line, but then the focus is NOT on a button, the default OK button has the focus effect, but not with a dahed line, indicating only a default action on ENTER press, as you said. So then, the real issue is that there is no visual indication that the actual tab is in focus and allows changing.
(In reply to Mihai Vasiliu from comment #7) > So then, the real issue is that there is no visual indication that the > actual tab is in focus and allows changing. @Heiko: Any thoughts/plans about this (currently focused tab item not clearly indicated on Windows)? (IIRC, you mentioned this earlier, but I don't know/remember what the result/plan was.)
Sure, we need to fix this. But it's also an issue for horizontal tabs. A known solution is a dotted frame around the text, ugly IMO. Color could be a used too, and actually a tiny difference in hue or brightness might be enough.
Created attachment 201681 [details] Horizontal tabs focus (In reply to Heiko Tietze from comment #9) > Sure, we need to fix this. But it's also an issue for horizontal tabs. > > A known solution is a dotted frame around the text, ugly IMO. > > Color could be a used too, and actually a tiny difference in hue or > brightness might be enough. I don't see any accessibility issue with horizontal tabs. The tab color is (or can) be different based on theme, and also there is a dotted line frame, which is not appealing, but standard on buttons as well.
Created attachment 201682 [details] Screenshot showing focused tab indicator for Kate with Breeze style
(In reply to Heiko Tietze from comment #9) > Sure, we need to fix this. But it's also an issue for horizontal tabs. > > A known solution is a dotted frame around the text, ugly IMO. What KDE's Breeze style does is to show an underline for the text of the currently focused tab. Attachment 201682 [details] that shows a screenshot of Kate where this can be seen. So for LibreOffice's Qt-based VCL plugins, implementing use of native widgets (tdf#130857) should make this work for LibreOffice as well. Platforms/VCL plugins using the VCL implementation (Windows, macOS, gen) still need to be considered/handled separately.