Description: With the browse mode you get completely different possibilities in word processors like Microsoft Office. It would be good if LibreOffice Writer would also support the browse mode. The navigator in LibreOffice is not sufficient. Further information can be found here: https://github.com/nvaccess/nvda/issues/8148 Actual Results: There is no browse mode in LibreOffice Expected Results: Lots of new possibilities thanks to a browse mode Reproducible: Always User Profile Reset: No Additional Info: -
We have read the github link and can confirm that the navigator in LibreOffice is not sufficient. For example, in Word in browse mode it is possible to navigate from spelling mistake to spelling mistake, which is not allowed by the LibreOffice navigator. In order to work with text documents faster and more efficiently, the implementation of the browse mode would be very useful.
If NVDA 'Browse mode' is dependent on any UIA, pretty clearly unsupportable in LibreOffice where we support only accessible event triggers--as mapped back to IA2. If we're missing accessible events, fine--that is on us. But, we will not implement native MS Windows code needed for UIA. Similar to 'Say-all' fix likely has to be within the the IA2 module of NVDA. But I won't close this NOT OUR BUG just yet. Need technical exchange from NVDA devs as to what's potentially required within IA2 event framework.
(In reply to V Stuart Foote from comment #2) > If NVDA 'Browse mode' is dependent on any UIA, pretty clearly unsupportable > in LibreOffice where we support only accessible event triggers--as mapped > back to IA2. > > If we're missing accessible events, fine--that is on us. > > But, we will not implement native MS Windows code needed for UIA. > > Similar to 'Say-all' fix likely has to be within the the IA2 module of NVDA. > > But I won't close this NOT OUR BUG just yet. Need technical exchange from > NVDA devs as to what's potentially required within IA2 event framework. Hello Stuart, has anyone from NVDA contacted you yet?
(In reply to juergenkohler23 from comment #3) > (In reply to V Stuart Foote from comment #2) > > If NVDA 'Browse mode' is dependent on any UIA, pretty clearly unsupportable > > in LibreOffice where we support only accessible event triggers--as mapped > > back to IA2. > > > > If we're missing accessible events, fine--that is on us. > > > > But, we will not implement native MS Windows code needed for UIA. > > > > Similar to 'Say-all' fix likely has to be within the the IA2 module of NVDA. > > > > But I won't close this NOT OUR BUG just yet. Need technical exchange from > > NVDA devs as to what's potentially required within IA2 event framework. > > Hello Stuart, > > has anyone from NVDA contacted you yet? Neither Quentin, Jaime, nor Mick--nor any of the developer community. It would/will be reflected here in the BZ.
Dear juergenkohler23, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
I have tried again to contact the NVDA developers; without their help the necessary information will probably not be available...
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to juergenkohler23 from comment #6) > I have tried again to contact the NVDA developers; without their help the > necessary information will probably not be available... Jürgen, any news? => NEEDINFO
(In reply to V Stuart Foote from comment #4) > > > If NVDA 'Browse mode' is dependent on any UIA, pretty clearly unsupportable > > > in LibreOffice where we support only accessible event triggers--as mapped > > > back to IA2. I can answer this (all speaking generally at least, since I haven't looked at the code on either side here) - while NVDA now uses UIA by default in recent builds of Word, because the experience there has improved to where it is better and more responsive than iA2 *in that situation* in general for the majority of users, we have otherwise (and still offer) iA2 support. So that should be possible in LO as well. I know one of our developers, Reef, commented previously that we weren't in a position to take on the whole project - https://github.com/nvaccess/nvda/issues/8148#issuecomment-744228528 - At the time he suggested looking at how NVDA handles browse mode using iA2 in browsers. I don't think we're currently in a better position to own the endeavour, but I'm happy to keep the dialog open.
As the Orca maintainer, who would like to implement Browse Mode in Orca for LO Writer, I suspect that a big blocker for NVDA is the fact that only the visible page's contents are in the accessibility tree. That's the only real thing blocking Orca. Orca (and NVDA) cannot navigate to the next heading or table or link or whatever if they have no way of knowing those things exist. See related https://bugs.documentfoundation.org/show_bug.cgi?id=35652.
(In reply to Joanmarie Diggs from comment #10) > As the Orca maintainer, who would like to implement Browse Mode in Orca for > LO Writer, I suspect that a big blocker for NVDA is the fact that only the > visible page's contents are in the accessibility tree. That's the only real > thing blocking Orca. Orca (and NVDA) cannot navigate to the next heading or > table or link or whatever if they have no way of knowing those things exist. > > See related https://bugs.documentfoundation.org/show_bug.cgi?id=35652. A related discussion is currently happening on the dev mailing list, thread starts here: [1] Similar to practical problems with Calc exposing all cells (see tdf#156657), concerns about exposing the whole Writer document content have been mentioned (see e.g. [2]). @joanie/all: Do you think the flows-from/flows-to relations (related: tdf#96492) could potentially be an alternative to always exposing the whole doc content, or some other (maybe still to be developed) navigation API as mentioned in [2]? Any further thoughts on that? [1] https://lists.freedesktop.org/archives/libreoffice/2024-June/092039.html [2] https://lists.freedesktop.org/archives/libreoffice/2024-June/092063.html
Michael: Regarding flows-to/flows-from as the alternative, that *might* be doable, however: 1. It will be super non-performant for large documents, at least in the case of AT-SPI2. The way AtspiCollection works is that a single query goes over dbus and the results are returned. If we instead have to use flows-to/flows-from, I believe that's going to be one query *per object* as Orca traverses the entire document. And in addition to those queries, Orca is going to have to do additional work to determine if the thing is part of the collection being sought. That additional work may involve more queries over dbus, possible one per each object retrieved. There may be a way to instead do all the work in AT-SPI2 to make it less horrible, but that would need some investigation and consultation with the AT-SPI2 maintainer. 2. (Much more minor) the flows-to/flows-from relations will have to provide access to all document objects. I believe they currently skip over things like tables and embedded objects.