Open an empty Writer document. Write some text with one wrong written word. Press F7 for the spelling dialog. If you have reached the field "Not in dictionary" after pressing many tabs or shift+tab you could hear the content of the wrong sentence. But there won't be spelled the wrong word. Remember: people with screen reader don't see the bold red font. And the screen reader won't recognize it, too. So they couldn't use the dialog in a right way. They could only press "Correct".
What platform/OS and screen reader is this? Works OK for me at least with Orca screen reader on Linux and the gtk3 VCL plugin (where native gtk3 widgets are possibly used). For an "fff" text, it reads this when tabbing into the field: "Not in dictionary panel. Not in dictionary text fff" Version: 7.1.0.0.alpha0+ Build ID: 446cac7cbbebb797903298ecb33dd08dedc1317e CPU threads: 12; OS: Linux 5.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 #1) > What platform/OS and screen reader is this? Tested with Orca on OpenSUSE 15.1 LO Version: 6.4.5.2 Build-ID: a726b36747cf2001e06b58ad5db1aa3a9a1872d6 CPU-Threads: 6; BS: Linux 4.12; UI-Render: Standard; VCL: gtk3; Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE Calc: threaded Could be I don't understand all the voice tries to say, but: I could only hear the whole sentence I wrote, not the special wrong written word. So I have to guess what is written wrong there.
(In reply to Robert Großkopf from comment #2) > Could be I don't understand all the voice tries to say, but: > I could only hear the whole sentence I wrote, not the special wrong written > word. So I have to guess what is written wrong there. Thanks for clarifying, same behaviour here (I missed that when reading the bug report the first time.)
This may or may not be relevant once somebody looks closer into this: While reading the Orca help, I came across the "Identifying Misspelled Words" section in [1], which says: > Most applications and toolkits indicate that a word is misspelled by > underlining that word with a red, squiggly line. The presence of this line is > typically exposed to assistive technologies as a text attribute. As a result, > you will find spelling errors amongst the text attributes you can > choose. By default, the spelling error attribute is enabled for both > speech and braille and will therefore be presented along with any > other attributes whose indication you have enabled. > > In addition to accessing the presence of spelling errors as a text > attribute, if you have key echo and/or word echo enabled and type a > word which is misspelled, when the spelling error indication appears, > Orca will announce "misspelled" so that you can immediately go back > and correct the error. > > Finally, when you are navigating within a document and the caret > moves into a word which is misspelled, Orca will announce the > presence of the spelling error. This is the case when moving the cursor in a Writer document, but not in the spelling dialog. Might make sense to take a closer look at this and how to properly expose the text attribute to AT. [1] https://help.gnome.org/users/orca/stable/howto_text_attributes.html.en
While text attributes for the misspelled word should properly be reported as described in comment 4, it might be useful to know in the meanwhile that the cursor/caret is positioned at the beginning of the misspelled word when the text field gets focus, see bug 102044.
(In reply to Michael Weghorn from comment #5) > While text attributes for the misspelled word should properly be reported as > described in comment 4, it might be useful to know in the meanwhile that the > cursor/caret is positioned at the beginning of the misspelled word when the > text field gets focus, see bug 102044. And it's also possible to find out what part of the text is in red by using the screen reader feature to report text formatting (if the screen reader has that, e.g. using the NVDA+F keyboard shortcut for NVDA and Orca+F for Orca), which can at least be a workaround.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0769e5e698a9cff77a815118dad82bc763520679 tdf#135236 gtk3 a11y: Restore AtkObject's focus_event It will be available in 24.2.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.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dff76b069e26a6d3487f74c5784d6f6cf273a19e tdf#135236 a11y: Notify a11y layer of WeldEditView sel change It will be available in 24.2.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.
I've started working on this and noticed a few more issues when testing this with Orca, s. the commit messages of the already merged changes. Bug 155447 is also related here, since Orca has special handling for the spelling dialog to provide an even better experience for users.
(In reply to Michael Weghorn from comment #9) > I've started working on this and noticed a few more issues when testing this > with Orca, s. the commit messages of the already merged changes. Unassigning for now as I currently don't have time to continue with this. (But I might come back to it later if nobody else gets to it earlier.)