Open an empty Writer document. Write some text with one wrong written word. Press F7 for the spelling dialog. The dialog sets the focus to "Correct". This behavior is nice for people who would see the content of "Not in dictionary", but if you have to work with a screen reader you have to jump back to "Not in dictionary" to hear the content of the wrong sentence. But this is only the first part of accessibility problems in this dialog. It's also part of bug 102044.
Agree, it's quite inconvenient - but it can be done, user needs to press shift-tab a few times (in any case, would likely be a behaviour change conditional to screenreader users) -> UX advise appreciated, and to me more an enhancement than a bug.
If you are using a screenreader, you have to make sure, that unnessesary typing is avoide, so you can work quicklyand the actual behaviour in this dialoque slows the work for screenreader users. Should be changed.
Additional: The mispelled word is only noteable, when the screenreaders announces color change, which is not regular.
Susanne, what do you think?
Created attachment 168147 [details] Screeshot Focus is on Correct, with shift+tab we go back to the "Not in directory" text.
Can we detect whether a screen reader is in use and make the focus depending on this?
(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
So let's change the initial focus. It's likely an easy hack. Code pointer: InitHdl() in cui/source/dialog/SpellDialog.cxx
Hi, I'm looking to contribute to LO and find this interesting, reading the above chats, can I take up the task of changing the initial focus as my first EasyHack here?
(In reply to Sarrah from comment #10) > Hi, I'm looking to contribute to LO and find this interesting, reading the > above chats, can I take up the task of changing the initial focus as my > first EasyHack here? Yes, as this single-task hack is not assigned to anyone, you can take it.
(In reply to Buovjaga from comment #11) > (In reply to Sarrah from comment #10) > > Hi, I'm looking to contribute to LO and find this interesting, reading the > > above chats, can I take up the task of changing the initial focus as my > > first EasyHack here? > > Yes, as this single-task hack is not assigned to anyone, you can take it. Didn't notice you were not in Cc, so replying again.
(In reply to Heiko Tietze from comment #8) > So let's change the initial focus. It's likely an easy hack. > > Code pointer: InitHdl() in cui/source/dialog/SpellDialog.cxx Typo in the path (dialog vs. dialogs), should be cui/source/dialogs/SpellDialog.cxx
Sarrah Bastawala committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e0b281b17b974d20f98a61804377cfae07753016 tdf#135234 : Change initial focus of SpellDialog It will be available in 7.4.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.
The commit from comment 14 changed initial focus -> closing this bug as fixed The NVDA screen reader on Windows announces the initial focus as expected. Note that Orca doesn't do so yet due to a different issue; I have created tdf#148136 to keep track of that.