Bug 135234 - Spelling dialog in Writer hard to use with screen reader
Summary: Spelling dialog in Writer hard to use with screen reader
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
6.4.5.2 release
Hardware: All All
: medium enhancement
Assignee: Sarrah
URL:
Whiteboard: target:7.4.0
Keywords: accessibility, difficultyBeginner, easyHack, skillCpp, topicUI
Depends on:
Blocks: Spell-Checking a11y, Accessibility Dialog
  Show dependency treegraph
 
Reported: 2020-07-28 13:52 UTC by Robert Großkopf
Modified: 2022-03-22 13:00 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Screeshot (28.77 KB, image/png)
2020-12-14 12:59 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2020-07-28 13:52:08 UTC
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.
Comment 1 Thorsten Behrens (allotropia) 2020-07-28 15:27:36 UTC
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.
Comment 2 Karl-Heinz Arkenau 2020-07-28 18:34:42 UTC
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.
Comment 3 Karl-Heinz Arkenau 2020-08-27 07:49:13 UTC
Additional: The mispelled word is only noteable, when the screenreaders announces color change, which is not regular.
Comment 4 Heiko Tietze 2020-12-14 12:58:05 UTC
Susanne, what do you think?
Comment 5 Heiko Tietze 2020-12-14 12:59:03 UTC
Created attachment 168147 [details]
Screeshot

Focus is on Correct, with shift+tab we go back to the "Not in directory" text.
Comment 6 Heiko Tietze 2022-02-02 09:34:34 UTC
Can we detect whether a screen reader is in use and make the focus depending on this?
Comment 7 Michael Weghorn 2022-02-03 13:18:50 UTC
(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
Comment 8 Heiko Tietze 2022-02-10 13:41:58 UTC
So let's change the initial focus. It's likely an easy hack.

Code pointer: InitHdl() in cui/source/dialog/SpellDialog.cxx
Comment 9 Sarrah 2022-02-20 04:44:39 UTC Comment hidden (obsolete)
Comment 10 Sarrah 2022-02-20 04:45:15 UTC Comment hidden (obsolete)
Comment 11 Buovjaga 2022-02-20 09:20:43 UTC
(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.
Comment 12 Buovjaga 2022-02-20 09:21:25 UTC
(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.
Comment 13 Buovjaga 2022-02-24 18:25:56 UTC
(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
Comment 14 Commit Notification 2022-03-22 12:42:10 UTC
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.
Comment 15 Michael Weghorn 2022-03-22 13:00:42 UTC
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.