https://bugs.documentfoundation.org/show_bug.cgi?id=135234
--- Comment #7 from Michael Weghorn <[email protected]> --- (In reply to Heiko Tietze from comment #6) > Can we detect whether a screen reader is in use and make the focus depending > on this? Technically, it should be possible to use some heuristics to detect (at least with a certain probability) whether or not a a screen reader (or at least whether any kind of assistive technology) is enabled. For Linux/AT-SPI, there is a D-Bus property, "org.a11y.Status.IsEnabled" which tells applications whether or not to enable accessibility [1]. For Windows, see our function 'HasAtHook' [2]. I haven't checked Mac, but guess there should be some way as well. However, after thinking about this for a while, I tend to be skeptical whether making the default focus dependent on whether AT is enabled would be the best way to handle such cases in general, since it adds complexity and doesn't fit all cases either. Different users have different workflows on how they use dialogs, and the spelling dialog is just one example. Thinking further, questions like "For what dialogs should we do that? Should we even add an option to make it configurable?" come to mind... Therefore, my personal take would currently be that it's reasonable to choose one default for all, taking different criteria into account (ideally described in our UX guideline; "the typical user workflow" and a11y are 2 aspects that come to mind). At the same time, try to make other ways of interaction possible in an efficient way. For interactive widgets in a dialog, there are mnemonics or keyboard accelerators, which I think are a good way to efficiently support different use cases. For example, in the spelling dictionary, the mnemonic for "Not in dictionary" is "N" (in the English UI), as indicated by the fact that the "N" is underlined. Therefore, pressing Alt+N will set the focus into the "Not in dictionary" element without having to press Shift+Tab multiple times. For "Correct", this is "r", so Alt+R triggers that. I think it makes sense to think what approach/direction to take in general, not just for the spelling dialog case by itself. Assuming the "one default for all" approach, for the spelling dialog case, I can think of a lot of different use cases that could be used to argue in favor of pretty much any of the available UI elements to be used as default ("Ignore Once/Ignore All" or "Add to Dictionary" because it happens often that LO doesn't know a specific word; "Suggestions", because there are often different alternatives to choose from, so it's better to choose first and then select "Correct" or "Correct All",...). Given this, the fact that it would improve a11y, that "Not in Dictionary" comes before the other buttons (and it's usually most "logical" to traverse elements from top to bottom), I'd personally agree with the suggestion to prefer "Not in Dictionary" over "Correct" for the default focus. (Power users could still use Alt+R to select "Correct" directly.) By the way, MS Word also puts focus on the "Not in Dictionary" element after correcting a word (which is also related to the previously mentioned bug 102044). That's my personal opinion, what do others think? [1] https://www.freedesktop.org/wiki/Accessibility/AT-SPI2/ [2] https://git.libreoffice.org/core/+/2eb00243a1d5596ed608a476a73b2d063ab09a49/vcl/source/app/salplug.cxx#440 -- You are receiving this mail because: You are the assignee for the bug.
