Description: I am using Windows 10 64-bit version 20H2, LibreOffice 7.2.4 and NVDA 2021.3. With Calc, it seems that the full accessibility hierarchy of a cell in Calc is being announced any time a change is made to that cell (e.g., entering a number, changing the format, etc.). I do not have any special settings in either NVDA or LO. The file I am working with is in Excel (.xlsx) format. When using JAWS and Excel, this issue does not exist. This is not a new issue; it has been present since at least LO 7.x. Also, other users on the NVDA support list report it. Michael Weghorn <m.weghorn@posteo.de> (a LO Developer) took a look at this issue. He was able to reproduce it. He also said that this issue does not occur when just navigating through the spreadsheet using the arrow keys (i.e., without making any changes) or when using the Orca screen reader with the gtk3 VCL plugin on Linux. He also added that to his understanding, screen readers usually only announce the "hierarchy" of a focused object up to the point from which it is different from the previously focused object. One potential explanation for this issue could be that for some reason it is not exposed to NVDA that the previously selected cell is a "sibling" of the one selected afterwards, or somehow focus is on another accessibility object in between. Steps to Reproduce: See description1. 2. 3. Actual Results: See description Expected Results: See description Reproducible: Always User Profile Reset: No Additional Info: See description
please retest with a 7.3 build. Also, MS Excel is not a "native" format--in genearl ODF Spreadsheet document will have better conformance and support in Libreoffice Calc. At 7.3 Michael W. has implemented IAccessible2 table and table cell support in the Calc UI. A 7.2 build will not make use of the enhanced AT provided.
For reference: This and tdf#146306 were originally reported/discussed on the accessibility mailing list, thread starts at https://listarchives.libreoffice.org/global/accessibility/msg00972.html . I can reproduce with a current master build. attachment 177025 [details] (from bug tdf#146306) is a screencast demonstrating the issues. (For the first cells, tab or enter were pressed right after entering the number, for the later ones, it's only pressed later, so you can hear the full cell announcement.) Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: c40df02caa6b5473f80bd8c2ed14763dac2076cd CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Created attachment 177517 [details] Screencast with LO 7.2.4.1
(In reply to Richard B. McDonald from comment #0) > With Calc, it seems that the full accessibility hierarchy of a cell > in Calc is being announced any time a change is made to that cell (e.g., > entering a number, changing the format, etc.). During a first analysis, I realized that it's not actually the whole hierarchy (any more) that is being announced with a current development version (e.g. the one used in screencast attachment 177025 [details]), while that was the case in LibreOffice 7.2, for which Richard has originally reported this issue. I have attached another screencast for LO 7.2: attachment 177517 [details] For LO 7.2, it says for example (around second 22 in attachment 177025 [details], manual transcript): "Untitled 2 - LibreOffice Calc, Untitled 2 LibreOffice spreadsheets document editable, sheet Sheet1 table editable, D8" For current master, it only says (around second 26 in attachment 177025 [details]): "sheet Sheet1 table editable, G12". That means, only a single additional hierarchy level is spoken in addition to the cell, the spreadsheet itself: "sheet Sheet1 table editable" So there's some improvement. Bibisecting points to this commit: commit 836a226205df9e76e77d26af80f402de7b876d61 Author: Michael Weghorn <m.weghorn@posteo.de> Date: Thu Sep 16 07:11:47 2021 +0100 tdf#100086 wina11y: Don't delete a11y object for removed cell right away From a first analysis, the reason for the spreadsheet still being announced is probably that there are two different a11y objects for the cell that just gets focus and the one that is edited. The one that "just has focus" has the spreadsheet as a parent object, the one that is edited doesn't, but has the document as parent (which is one level further up in the hierarchy), so when switching from the latter to the former, that additional level is announced by NVDA. From what I can see, the a11y object for the editable cell is created here (comment about the hierarchy added by myself while looking into this): --- a/sc/source/ui/Accessibility/AccessibleDocument.cxx +++ b/sc/source/ui/Accessibility/AccessibleDocument.cxx @@ -1503,7 +1503,7 @@ void ScAccessibleDocument::Notify( SfxBroadcaster& rBC, const SfxHint& rHint ) ScViewData& rViewData = mpViewShell->GetViewData(); const EditEngine* pEditEng = rViewData.GetEditView(meSplitPos)->GetEditEngine(); if (pEditEng && pEditEng->IsUpdateLayout()) - { + { // note how the ScAccessibleEditObject is created here, and gets the document as parent, not the spreadsheet mpTempAccEdit = new ScAccessibleEditObject(this, rViewData.GetEditView(meSplitPos), mpViewShell->GetWindowByPos(meSplitPos), GetCurrentCellName(), ScResId(STR_ACC_EDITLINE_DESCR), ScAccessibleEditObject::CellInEditMode); So, one approach might be to set the spreadsheet as parent for the corresponding 'ScAccessibleEditObject' as well. However, that would need more work, since just doing so in this place breaks things elsewhere. Some things currently rely on the implementation as it is. Given this will probably take more time to look into, I'll leave that aside for now (but *might* come back to it at some point in time in the future).
Dear Richard B. McDonald, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug