This ticket is based on previous discussion in tdf#160824, quoting from my tdf#160824 comment 11: I'd suggest to change initial focus to the "Printer" combobox at the top of the dialog, which to me seems more logical and also better for accessibility: Tabbing from top to bottom in the visual order is more logical than starting somewhere in the middle of the dialog and having to Shift+Tab to get up to the printer first. (And some controls in the dialog like the page size change dependent on the printer selection, so the printer should really be selected first.) Note that initial focus on the "Number of copies" spinbox was previously implemented in the context of tdf#34641 (as OpenOffice.org also used to do this), but I personally agree with bug 34641 comment 1: > If no arguments will be found against this, I would prefer to open print dialog with focus on printer selection as in other programs. > I agree, start focus on "No of copies" might be useful, but I would prefer consistence. (Changing that would be easy, just replacing the `mxCopyCountField->grab_focus();` in `PrintDialog::PrintDialog` in vcl/source/window/printdlg.cxx .) # Steps to reproduce: 1) start LO Writer 2) Ctrl+P to open the print dialog # Actual behavior: Initial focus is on the "Number of copies" spinbox in the middle of the dialog # Expected behavior: Initial focus should be on the "Printers" combobox at the top of the dialog. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: bcc1b9f22d4b2772c735176e78dfa1e7c8c39b3a CPU threads: 32; OS: Linux 6.7; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
(In reply to Michael Weghorn from comment #0) > # Expected behavior: > > Initial focus should be on the "Printers" combobox at the top of the dialog. That's my personal opinion of course, for the reasons given above. I don't really have strong feelings about it, though - up to the UX team to decide.
And my reply (In reply to Heiko Tietze from comment #12) > From the efficiency POV, the most relevant function should be in focus. And > that's the number of copies: ctrl+P into the dialog, arrow up as many copies > you like, and enter to run the action. > > Admittedly it's odd to start tabbing (or screen reading) in the middle of a > dialog.
(In reply to Heiko Tietze from comment #2) > And my reply > > (In reply to Heiko Tietze from comment #12) > > From the efficiency POV, the most relevant function should be in focus. And > > that's the number of copies: ctrl+P into the dialog, arrow up as many copies > > you like, and enter to run the action. > > > > Admittedly it's odd to start tabbing (or screen reading) in the middle of a > > dialog. But the actual printer selection *is* the more significant condition. Knowing it before configuring print range and number of copies is crucial, especially as the range and number of copies have reasonable default. While printer selection takes a value from os/DE default or as recorded to ODF archive for a document. And that means the user will not know what printer is selected on opening the dialog! Very serious situation as the printer could be a disconnected network printer, or a remote network printer, or a "print to file" printer resource. So rather than the copy count (and needed 10 <Tabs> round to reach the printer listbox), starting from the printer selection is the more conservative/appropriate landing. It certainly is from an a11y point! +1, change the dialog landing to the "Printer" listbox selector.
-1 that would be awful. Every time I print I set the printing options once, and then print multiple times, changing only the number of pages to print (and the range of pages to print). The number of copies to print is the most important setting for me.
We discussed the topic in the design meeting. The number of copies might be the primary function for many of not most users but can be reached easily from the top-most control per alt+N (or the respective mnemonic depending on localization). In general it's advised to start on top not least to ease the navigation for disabled users with screen readers.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0764a44e185d7b940f442cc054f5f1afd8c5cc64 Resolves tdf#161082 - Set focus on topmost item (Printer) It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks Heiko! Fix verified with Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: c32d97c5a5d6f94713feaf7867abb1ce11cf9a14 CPU threads: 32; OS: Linux 6.7; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: CL threaded