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: 184.108.40.206.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
with the latest Orca (3.20.2) and latest LibrOffice fresh (5.1.4) the problem continues to appear.
*** 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 220.127.116.11 (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!
I can confirm with version 18.104.22.168.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
*** 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
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:
> 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 22.214.171.124 (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