Summary: | Spelling dialog not usable with screen reader - wrong written word couldn't be found | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Robert Großkopf <robert> |
Component: | UI | Assignee: | Michael Weghorn <m.weghorn> |
Status: | ASSIGNED --- | ||
Severity: | normal | CC: | m.weghorn, thb |
Priority: | medium | Keywords: | accessibility |
Version: | 6.4.5.2 release | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=135234 https://bugs.documentfoundation.org/show_bug.cgi?id=102044 https://bugs.documentfoundation.org/show_bug.cgi?id=155447 |
||
Whiteboard: | target:24.2.0 | ||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 96000, 101912, 102019 |
Description
Robert Großkopf
2020-07-28 14:01:00 UTC
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. |