This occurs in EDITING when using a screen reader NVDA 2016.1jp. Procedures 1)Enter 'apple' in cell A1, 'orange' in A2, 'pair' in A3. 2)Focus the A1 cell by cursor. 3)Press shift+down key. 4)Press shift+down key. Readouts by NVDA at the procedure above 2)apple A1 3)(no sound) 4)(no sound) We would like LibreOffice Calc to read out them like in Excel, if not, at least in OpenOfficeCalc 4.1.1. Readouts when Excel is used 3)from A1 apple to A2 orange selected 4)from A1 apple to A3 pear selected Readouts when OpenOfficeCalc 4.1.1 is used 3)orange selected A2 4)pear selected A3
On Windows 10 Pro 64-bit en-US withVersion: 5.1.3.2 (x64) Build ID: 644e4637d1d8544fd9f56425bd6cec110e49301b CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Locale: en-US (en_US) With NVDA 2016.1 installed and functioning, accprode (w/x86 JRE) monitoring events. Confirming. Seems like we get additional accessible events beyond doing the cell selection. Could someone check what Orca exposes.
I tested with Orca on FreeBSD. Nothing is spoken when pressing Shift in conjunction with the arrow keys. It seems as though the cells are selected, however, nothing is spoken by the screen readers to indicate the extent of the selection.
Tested Orca on Ubuntu Mate and step 3 and 4 resulted in no sound.
Should the importance of this bug get upgraded? This is really probably a show stopper for assistive technology users trying to use the spreadsheet application. When selecting a large group of cells, it is extremely difficult to count the cells with no audio feedback.
(In reply to am_dxer from comment #4) > Should the importance of this bug get upgraded? No the priority and impact are correctly set. The "a11y" meta and "accessibility" keyword keep topic in focus for Calc developers.
Kohei just finished fixing bug 71409, so hopefully he could look at this a11y calc bug as well.
Repro in 4.4.0.2. Must be older.
Repro in 3.5.7.2. Must be older.
Dear all, Joanie: Do we have the correct events emitted on GNU/Linux ? Since the resolution of the bug 93825 we have "object:state-changed:selected" events emitted but I'm not sure it is sufficient for Orca. Best regards.
** 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
Isn't this essentially a duplicate of 93825? Still I think there are more issues with this implementation we just slowly need to document it. === Steps to reproduce === * Grab the accessible listener from 93825 * Launch libreoffice calc spread sheet * Press shift+space to select entire row * Now launch the accessible event listener in a terminal * Focus back to the calc window * Press and hold down shift key and repeatedly press left arrow key several times. 5 or 10 times is fine to see the issue in action. * Examine the event listener output in the terminal window === Expected result === Corresponding with switching back into the calc window single object:active-descendant-changed is expected. Then number of object:selection-changed events is expected for each selection contraction. So if you have pressed shift+left arrow keys 5 times you should have at least 6 events printed to the terminal window. === Actual result === Corresponding accessibility event is only being sent for the first selection change resulting from pressing shift+left arrow key. Second, third and all other shift+left key presses don't generate appropriate accessibility events. === Notes === I think windows screen readers such as NVDA don't handle this at all so on windows work shal be done on both ends of the stack. Also I think there might be more issues like this we haven't yet clearly documented them.
I've added Tamas in CC to answer to Peter comment #11 because he has resolved the issue #93825 Best regards, Alex.
Dear minakonono3519, 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
Dear Libre office team, Testing with Libre Office 7.4.4.2 and Open Office 4.1.7, in both cases the sellected cell range is not reported. The expected behavior when pressing shift+arrow keys is to report the sellected cell range (i.e. a1 through a3 when pressing shift+down arrow key two times). I am testing with NVDA 2020.1.
Sorry I meant Libre Office 6.4.4.2 of course.
Following up on this, What needs to happen to get some time put towards fixing this? If i'm not mistaken selection does work on libreoffice with orca. But nvda and windows still have troubles.
Corresponding issue in NVDA's issue GitHub issue tracker: https://github.com/nvaccess/nvda/issues/6897 FYI: I have a local work-in progress branch for implementing IAccessibleTable2 and IAccessibleTableCell support for winaccessibility in LO and hope to find some time to continue with this (presumably in September). This might help here, but more will have to be done (on LO and/or NVDA side).
Created attachment 174894 [details] NVDA demo patch to use IAccessibleTable2 and IAccessibleTableCell interfaces in LO Pending Gerrit changes to add support for the IAccessibleTable2 and IAccessibleTableCell interfaces to LibreOffice: https://gerrit.libreoffice.org/c/core/+/121820 https://gerrit.libreoffice.org/c/core/+/121821 As mentioned in my previous comment, this isn't enough. For demo/testing, I used the attached demo patch to NDVA (on top of master as of 8979880164cae91209436e57b414b063625e92e0) to access and print information about the currently selected cells using those interfaces. (It's not fit for integration in NVDA as is, just a test/demo usage of the interfaces.)
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/839dbf9ecf9f8fbec7de983d1a2e16d7de6f868c tdf#100086 tdf#124832 wina11y: Implement IAccessibleTable2 It will be available in 7.3.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/97a88e30e2e084ab860635ff4e0a03442d8a12af tdf#100086 tdf#124832 wina11y: Implement IAccessibleTableCell It will be available in 7.3.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/836a226205df9e76e77d26af80f402de7b876d61 tdf#100086 wina11y: Don't delete a11y object for removed cell right away It will be available in 7.3.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.
Some further discussion currently going on in this NVDA issue: https://github.com/nvaccess/nvda/issues/9310 It works with LO master and a current draft NVDA pull request by Leonard de Ruijter: https://github.com/nvaccess/nvda/pull/12849
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1b94deea2c7648255e3efac08fd352f80c2bda06 tdf#100086 wina11y: Return "fresh" IEnumVARIANT for get_accSelection It will be available in 7.3.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 #22) > Some further discussion currently going on in this NVDA issue: > https://github.com/nvaccess/nvda/issues/9310 > > It works with LO master and a current draft NVDA pull request by Leonard de > Ruijter: https://github.com/nvaccess/nvda/pull/12849 The NVDA PR is now scheduled to be merged for NVDA 2022.1. I'm closing this bug, since the LO side has already been merged and will be available from LO 7.3 on. In case you still encounter any issues with LO >= 7.3 and NVDA >= 2022.1, please file new bug reports with details on what exactly is not working as expected.