When composing a document, and the user wishes to add a comment, once you press the Control+Alt+C keybinding to add a comment to a highlighted portion of text, or to a area of text that is proceeding the cursor, Orca does not interact with the comment field. Arrowing through the text typed out provides no speech output. Deleting text does not provide speech output. Activating the menu item under Insert, Comment, yields the same result. Using the Control + Alt + Page Up and Page Down functions to cycle through comments only reads the text written out for that particular area that is commented, does not allow navigation to the actual comment itself with orca. Perhaps provide a keybinding that will get to the list of comments presented should there already be some?
Migrating Whiteboard tags to Keywords: (a11y -> accessibility)
I can confirm with Version: 5.2.0.0.alpha1+ Build ID: eb7593daa4bac21bd68182c8bbbd3ee3bd7b64dd CPU Threads: 4; OS Version: Linux 4.4; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-05-03_07:06:45
Dear all, with the latest Orca (3.20.2) and latest LibrOffice fresh (5.1.4) the problem continues to appear. Best regards.
*** Bug 101002 has been marked as a duplicate of this bug. ***
Confirmed with 5.2.1 on windows with NVDA.
This issue still exsits in LibreOffice 5.4.2.2 (x64) using NVDA 2017.3. Issue on NVDA issue tracker: https://github.com/nvaccess/nvda/issues/7700
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I can confirm with version 6.3.0.0.alpha0+ Build ID: 4187b2beaa3d1294cd5c76ec0b662f3f4fadc421 Threads CPU : 12; OS : Linux 4.19; UI Render : par défaut; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-02-25_07:04:36 Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded
*** Bug 106180 has been marked as a duplicate of this bug. ***
*** Bug 135439 has been marked as a duplicate of this bug. ***
I have looked at the bugs that have been marked as a duplicate of this one or that are indirectly linked to it: * Bug 92389 - Writer: Comment text not accessible with screen reader Reported without reference to a specific OS; confirmed both on Linux with Orca (until 2019) and on Windows with NVDA (2017). * Bug 99261 - Calc: Comment not supported with screen reader Reported for Windows (tested with both Jaws and NVDA); confirmed on Linux with Orca * Bug 101002 - Comments in Impress are not accessible (adding/reading) Reported for Linux with Orca; comments mention both keyboard interaction problems and missing accessibility metadata (checked using accerciser). * Bug 102054 - Allow access and modifying of comment with keyboard Reported without reference to a specific OS; bug focuses on keyboard interaction * Bug 102058 - No screen reader notification that there is a comment Reported without reference to a specific OS; confirmed on Linux with Orca (until 2018). * Bug 106180 - No screen reader notification that there is a comment Reported without reference to a specific OS (but split off from bug 102058); confirmed on Linux with Orca (2018). * Bug 135439 - Accessibility: No output from screenreader when adding a comment in Writer Reported for Windows (with unidentified screen reader); confirmed on Linux and repeatedly on Windows. Based on the above reports, the bug seems to be caused by two issues: (1) missing role information in the accessibility API (see issues 92389, 102058, 106180 and 135439) and (2) the absence of keyboard accessibility (originally reported in 99261 and contradicted there, but see my findings below). My findings regarding keyboard access are the following: In LibreOffice Writer, you can indeed insert a comment using either the shortcuts Crtl + Alt + C or through the menu items Insert -> Comment; you can get out of the comment using Esc. However, editing an existing comment later on appears to be impossible: you can browse the list of existing comments in the Navigator, but pressing Enter on a specific comment takes you to the document's text, not to the comment. (In LibreOffice Calc, you can open an existing comment again when you press Shift + F10 to open the cell's context menu and then choosing "Edit comment". This does not work in Writer or Impress. In addition, you exit a comment in Writer or Calc by pressing Esc, whereas this does not seem to work in Impress, where I use F6.) I am not 100% certain what the exposed accessibility role should be; the closest match seems to be IA2_ROLE_NOTE in IAccessible2 and ROLE_COMMENT in ATK/AT-SPI. See the "Role Mapping Table" in "Core Accessibility API Mappings 1.1" at https://www.w3.org/TR/core-aam-1.1/#mapping_role_table Question: Linux, Windows and Mac OS use different accessibility APIs. Should there be just one open bug for this issue in spite of this? Or one for the Windows version and one for Linux (and perhaps another one for Mac OS)?
@Michael W, another a11y issue you might enjoy quashing, similar to the table cell roles, has additional accessible role tweaks needed. Stuart
Created attachment 175683 [details] Screenshot of Writer comment hierarchy in Accerciser
Created attachment 175684 [details] Sample doc used for creating Accerciser screenshot
For Writer, a good starting point to further look into this is 'sw/source/uibase/docvw/SidebarWinAcc.cxx', which contains the a11y implementation for 'SwAnnotationWin'. Navigating through the hierachy of the attached sample doc, attachment 175684 [details], in Accerciser (using LO with gtk3 VCL plugin in Linux) reveals that "something" is already exposed to AT, s. the node with role "comment" and its children as well as my comments in the Accerciser screenshot, attachment 175683 [details]. This presumably needs to be improved further. (In reply to V Stuart Foote from comment #12) > @Michael W, another a11y issue you might enjoy quashing, similar to the > table cell roles, has additional accessible role tweaks needed. Stuart @Stuart: Thanks. I can't really look further into this at this point, but maybe I'll find some time at some point in the future, yet can't promise anything. (In general, I'm subscribed to the a11y meta bugs and hope to find some time to take a look at one or the other bug at some point.) (In reply to Christophe Strobbe from comment #11) > I have looked at the bugs that have been marked as a duplicate of this one > or that are indirectly linked to it: > [...] > > Question: > Linux, Windows and Mac OS use different accessibility APIs. Should there be > just one open bug for this issue in spite of this? Or one for the Windows > version and one for Linux (and perhaps another one for Mac OS)? Thanks for the detailed analysis! I'd say having one bug for all platforms is fine for now. Should a solution only be implemented for one platform at first, we can still open a follow-up bug for the remaining ones.
(In reply to Quentin Christensen from comment #6) > This issue still exsits in LibreOffice 5.4.2.2 (x64) using NVDA 2017.3. > > Issue on NVDA issue tracker: https://github.com/nvaccess/nvda/issues/7700 And there's also https://github.com/nvaccess/nvda/issues/11684, referring to bug 135439 which has been closed as a duplicate of this one here.
detailed specifications. thank you for sharing! https://super-mario.io
Same in OOo 3.3: characters read aloud by Orca when entered, but not when navigating existing text with cursor. Still current in recent trunk build: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4d381b54d1c598c181b4a21a8bf0db86eb4668d1 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
(In reply to Stéphane Guillou (stragu) from comment #18) > Same in OOo 3.3: characters read aloud by Orca when entered, but not when > navigating existing text with cursor. I can reproduce that with single-line comments. Interestingly, text *is* announced by the screen reader for me when having comments with multiple paragraphs in them. Example: 1) start Orca 2) open attachment 175684 [details] 3) click into the comment using the mouse -> comment not read out 4) move cursor using the arrow keys on the keyboard -> comment not read out 5) move to end of the comment text, press Enter and then type "Hello world" 6) click into document 7) repeat steps 3-5 -> text is now read out just fine step 6 is optional. Maybe this is not only about single/multi line, but when creating a new doc with new comments, multiline ones are also announced, single line ones are not. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1db5b87fe69c2375f1d66974dafcd563303c76db CPU threads: 12; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/512b09ec51cfbe9bb0ce1a7f229b443dc427f6f3 tdf#92389 sw a11y: Use SolarMutex in SidebarWinAccessibleContext It will be available in 24.8.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.
(In reply to Michael Weghorn from comment #19) > Maybe this is not only about single/multi line, but when creating a new doc > with new comments, multiline ones are also announced, single line ones are > not. When looking into this a bit more, it actually wasn't just about single/multi line, but something else seems to play a role also. The commit from comment 20 doesn't fix the overall issue, but only a related crash I ran into.
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/cc88d26c8ebcf1dd828469eead40d7747f2b9129 tdf#92389 sw a11y: Use SolarMutex in SidebarWinAccessibleContext It will be available in 24.2.2. 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.