if open the find and replace window (e.g. ctrl-h), I can enter a search string straight away (curson=r is in the "find" text entry field). If <tab> is pressed to skip to the next field it goes to various buttons before getting to the "replace" text entry field. A more useful flow would be for the <tab> key to go from the "find" field directly to the "replace" field with the buttons then to follow.
UX needs to decide this one.
But what if people use this dialog to just find something, perhaps in order to save the vertical space of the find bar? And for the sake of safety first you execute 'find next' on enter whether pressed at the search or the replace input. If we follow your suggestion it makes only sense when the two find buttons are removed, which makes the dialog a little bit more familiar. Another remark: Have you considered to use the shortcut alt+p (depending on your localization) to jump to the replace input? Not that convenient as tab but better than tripple-tab.
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
Closing now.
Keyboard <TAB> navigation is alternative to the mouse driven GUI--and in the case of the common use Find & Replace dialog each <Tab> checkbox advance (variable depending on module) control attributes of the Find action. The sequence is correct as the Find must be fully configured before the Replacement can be configured/entered. Additionally, controls must remain consistent for a11y considerations. Keyboard movement jumping backward, or haphazardly, in a dialog is disruptive. IMHO => WF was appropriate, and remains so.
Proposal: Move the search modifiers above the "Find" input field. Initial focus upon opening the "Find and Replace" dialog should stay on the "Find" input field. With this solution, it would be possible navigate to the "Replace" input field by pressing the tab key two times. Additional proposal: Put a hint for the possibility to use Alt+P to navigate to the "Replace" input field.
*** Bug 141227 has been marked as a duplicate of this bug. ***
Created attachment 170745 [details] F&R at Kate Not above but maybe below like Kate does (the KDE text editor)