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.
