[libreoffice-accessibility] Conform.
-- To unsubscribe e-mail to: accessibility+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/accessibility/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [orca] Re: [libreoffice-accessibility] menu navigation issue
On 2024-06-11 14:29, Jason J.G. White wrote: On 11/6/24 07:38, Joanmarie Diggs wrote: BTW, are you using Wayland and gnome-shell? If so, it sounds like https://gitlab.gnome.org/GNOME/mutter/-/issues/3267. Although that was fixed four months ago. Yes, it's GNOME-Shell under Wayland. I just tried it again under a GNOME-Shell X11 session, and I am unable to reproduce the bug there. The version of Mutter is 46.2. I'm using KDE Plasma Wayland (plasma-workspace-wayland 4:5.27.11.1-1), can confirm that there the problem also isn't reproducible any more when running on X11/XWayland by setting environment variable `GDK_BACKEND=x11`. -- To unsubscribe e-mail to: accessibility+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/accessibility/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [orca] Re: [libreoffice-accessibility] menu navigation issue
On 11/6/24 07:38, Joanmarie Diggs wrote: BTW, are you using Wayland and gnome-shell? If so, it sounds like https://gitlab.gnome.org/GNOME/mutter/-/issues/3267. Although that was fixed four months ago. Yes, it's GNOME-Shell under Wayland. I just tried it again under a GNOME-Shell X11 session, and I am unable to reproduce the bug there. The version of Mutter is 46.2. -- To unsubscribe e-mail to: accessibility+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/accessibility/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [orca] Re: [libreoffice-accessibility] menu navigation issue
Hey Jason. I'm not able to reproduce this. That said, when you're interacting with an apps UI (e.g. navigating in menus), Orca is simply presenting the new location based on the events it receives. So I don't think it's an Orca issue. BTW, are you using Wayland and gnome-shell? If so, it sounds like https://gitlab.gnome.org/GNOME/mutter/-/issues/3267. Although that was fixed four months ago. --joanie On Tue, 2024-06-11 at 06:24 -0400, Jason J.G. White wrote: > Adding the Orca list to this discussion, as the bug may be a GTK or Orca > issue, as Michael helpfully details below. > > On 11/6/24 00:39, Michael Weghorn wrote: > > On 2024-06-10 14:14, Jason J.G. White wrote: > > > I noted the following on the Orca mailing list recently, but others > > > were unable to reproduce it. > > > > > > The issue below is not a priority for me at the moment, but I'm > > > reporting it here in case it can be resolved to prevent others from > > > encountering it. > > > > > > Environment: LibreOffice 24.2.4, GNOME 46.2, recent Orca version from > > > the main Git branch, Arch Linux distribution. I also tried the > > > version of LibreOffice available as a flatpak, with the same results. > > > > > > Steps to Reproduce > > > > > > 1. From LibreOffice Calc or LibreOffice Writer (both tested), F10 to > > > move focus to the menus. The File menu item is in focus, and Orca > > > presents it. > > > > > > 2. Right-Arrow. > > > > > > Expected Result: focus should move to the Edit menu, and subsequent > > > left/right-arrow navigation should move among the top-level menu items. > > > > > > Actual result: focus seems to move back into the document. I am > > > unable to navigate the menus reliably. Using the Alt key with various > > > letters does bring focus to the respective top-level menu items. > > > > > > > I can reproduce something similar with gtk3-demo and Orca git main, so > > it looks like an issue in either GTK or Orca to me, not in LibreOffice: > > > > 1) start gtk3-demo > > 2) start the "Menus" sample app > > 3) press F10 to put focus on the menu (the first item: "test line") > > 4) press right arrow > > > > Actual result: > > > > Keyboard focus visually moves to the next menu item "foo" as expected > > (visually), but Orca announces "Flip, push button" (which is the > > button in the sample program that has focus once the menu gets > > collapsed again) > > > > Expected result: The newly focused menu item should get announced: > > "foo, menu" > > > > This isn't 100% reproducible: When further moving back and forth > > between the menu items using the arrow keys, announcement is usually OK. > > > > Versions used, on Debian testing: > > > > libgtk-3-0:amd64 3.24.41-1 > > Orca git main as of commit 9b8d9ffd8793bf3a1176fed77b4ce283a43cefe8 > > > ___ > Orca mailing list > o...@freelists.org > https://www.freelists.org/list/orca > General information: https://orca.gnome.org > Orca documentation (English): https://gnome.pages.gitlab.gnome.org/orca/help/ > Orca documentation (translations): https://gnome.pages.gitlab.gnome.org/orca/ -- To unsubscribe e-mail to: accessibility+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/accessibility/ Privacy Policy: https://www.documentfoundation.org/privacy
[libreoffice-accessibility] Re: [a11y] LibreOffice Calc exposes 2^31 children, freezes on `GetChildren`
Hi Michael, Some great questions and points here; forgive my intruding into the space again =) On 11/06/2024 08:55, Michael Weghorn wrote: Limiting children to the to "close to visible" cells sounds like a potential approach. For a performant, caching AT I would argue this is arguably the only feasible option =) But ... the navigation API I mentioned is important. However, that would IMHO still need a clear specification on how to implement it and how all relevant AT use cases are covered. Agreed =) Some aspects/questions that might need some further consideration: * How do other interfaces (like AT-SPI Table, TableCell and Selection) expose information? Does e.g. the table report it only has 50 rows and 30 columns if that's what's visible on screen? Does cell Q227 report a row and column index of 0 if it's the first one in the visible area? I think exposing the whole thing through the Table interface may make some sense; it is clearly a crazy set of cells - and think it's reasonable to blame ATs if they use this interface for doing something silly. * In some cases, off-screen children are of interest, e.g. if they are contained in the current selection. How should that be handled? (e.g. how does the screen reader announce something like "cell A1 to C100 selected" if cell A1 "doesn't exist" because it's off-screen? Right; so - I mentioned "near to the screen" - by near; I mean we will probably want a number of things that are navigationally close: eg. "next heading" or somesuch - to lurk around as real & tracked peers. The content of the Navigator headings should prolly always be present in a writer document's object hierarcy IMHO. That should let ATs very quickly enumerate headings, jump focus to them with a simple API etc. * Exposing and caching all cells based on visibility means that whenever the view port changes, this needs to be actively updated (push approach), which comes with a cost (that I can't estimate right now). (We currently have that for other modules, see e.g. comment [3] for That is the case; we do that for writer on page-down of course. * How do screen readers implement features like "read the whole row"? This comes down to the navigation API I mentioned: having a good API to allow continuous screen-reading of large data-sets - with caching pre-loading & fetching along eg. a selection is really useful. Current writer behavior is far from optimal since you need to do something odd to get a simple navigation such as "next page" IIRC. Do they just read the part of the row that's currently visible on screen and leave out the rest? Or do they somehow implement some extra logic to retrieve the remaining content? Extra navigation / enumeration logic I think. * Is navigating to an "arbitrary" cell still possible via a11y API, e.g. if some screen reader specific table navigation command implements "jump to the first/last cell in the table" or "select the current row")? There should be a widget for this at the top of calc to jump to and select cells - if I were customizing an AT I'd use that. though of course it is then ideal to have some nice navigation API support wrapped around that What kind of API does that refer to? Existing or new API on the platform a11y level that LO (or the toolkits it uses) would then implement, or something else? Do you have anything particular in mind? I was actually somewhat optimistic about the UIA API Navigation API conceptually: https://learn.microsoft.com/en-us/windows/win32/api/uiautomationcore/nf-uiautomationcore-irawelementproviderfragment-navigate Although - I'd really suggest that a11y doesn't work against the application, and if navigating - it should allow the AT to scroll the actual visible/view-port to match what is being interrogated. I've been told repeatedly that the fact that Writer doesn't expose off-screen document content is indeed a problem as it breaks features like browse mode/document navigation in NVDA or Orca (see e.g. tdf#35652, tdf#137955, tdf#91739, tdf#96492). I'm not convinced that "can't see it in Accerssisor" is a real problem; what we all want are fast, accurate and helpful ATs for the impaired. Perhaps I mis-understand, but browse-mode seems conceptually similar to navigating by scrolling the current window down a document - without changing the cursor/document focus. to look into at some point. My idea so far is to also expose pages on the a11y level, which should avoid the problem of a single object (the document) having an enormous amount of children due to that. If there any general concerns about that, please raise them. :-) I guess this moves the problem to re-pagination; where we can get 300+ pages re-built for the sake of moving a single paragraph; then again - I guess if we are notifying changes in position on large sets of accessible
Re: [libreoffice-accessibility] menu navigation issue
Adding the Orca list to this discussion, as the bug may be a GTK or Orca issue, as Michael helpfully details below. On 11/6/24 00:39, Michael Weghorn wrote: On 2024-06-10 14:14, Jason J.G. White wrote: I noted the following on the Orca mailing list recently, but others were unable to reproduce it. The issue below is not a priority for me at the moment, but I'm reporting it here in case it can be resolved to prevent others from encountering it. Environment: LibreOffice 24.2.4, GNOME 46.2, recent Orca version from the main Git branch, Arch Linux distribution. I also tried the version of LibreOffice available as a flatpak, with the same results. Steps to Reproduce 1. From LibreOffice Calc or LibreOffice Writer (both tested), F10 to move focus to the menus. The File menu item is in focus, and Orca presents it. 2. Right-Arrow. Expected Result: focus should move to the Edit menu, and subsequent left/right-arrow navigation should move among the top-level menu items. Actual result: focus seems to move back into the document. I am unable to navigate the menus reliably. Using the Alt key with various letters does bring focus to the respective top-level menu items. I can reproduce something similar with gtk3-demo and Orca git main, so it looks like an issue in either GTK or Orca to me, not in LibreOffice: 1) start gtk3-demo 2) start the "Menus" sample app 3) press F10 to put focus on the menu (the first item: "test line") 4) press right arrow Actual result: Keyboard focus visually moves to the next menu item "foo" as expected (visually), but Orca announces "Flip, push button" (which is the button in the sample program that has focus once the menu gets collapsed again) Expected result: The newly focused menu item should get announced: "foo, menu" This isn't 100% reproducible: When further moving back and forth between the menu items using the arrow keys, announcement is usually OK. Versions used, on Debian testing: libgtk-3-0:amd64 3.24.41-1 Orca git main as of commit 9b8d9ffd8793bf3a1176fed77b4ce283a43cefe8 -- To unsubscribe e-mail to: accessibility+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/accessibility/ Privacy Policy: https://www.documentfoundation.org/privacy
[libreoffice-accessibility] Re: [a11y] LibreOffice Calc exposes 2^31 children, freezes on `GetChildren`
On 2024-06-11 10:48, Michael Weghorn wrote: On 2024-06-11 10:07, Samuel Thibault wrote: Michael Weghorn, le mar. 11 juin 2024 07:55:47 +, a ecrit: The feedback I've received from a11y experts so far is that off-screen doc content should *generally* be exposed on the a11y level, and limiting Calc to not do that with its huge amount of table cells is meant to be an exception to the rule in that regard (see e.g. the discussion in [2] and tdf#156657). I guess we can have the same kind of issue with a >>100 pages writer document? I would expect that there should still be way less objects than for the Calc case and the child count of each individual object will be lower (when Writer pages are reflected in the a11y tree, which they currently are not). In a first quick experiment with a local WIP branch, nothing was obviously broken right away when opening a ~800 pages Writer doc (but just containing simple text, nothing more complex) and moving around a bit while Orca was running or inspecting the tree using Accerciser. But of course, if some AT (or some underlying library) recursively queries and caches the whole tree and very complex documents are involved, then similar performance issues seem possible. (macOS and Win also need explicit testing, of course.) To me, this whole topic seems to be basically the same as the anticipated and still-to-be-solved performance aspect with the push approach that the alleged AT-SPI2 successor (codename "Newton") already mentions in its concept, see e.g. https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/142 Hopefully, a clear concept will come out of the work on the new protocol. Otherwise, as long as the underlying platform a11y protocols are pull-based and given the input I've received up to this point, I tend to think that ATs actively querying the tree are primarily responsible for limiting that to a reasonable amount of information, but I'm thankful for any guidance here... Technically, platform-specific handling of how much information is exposed would be possible, obviously adding a certain amount of complexity and maintenance burden. PS: CC'ing the accessibility mailing list, where people with more insights on the AT side are subscribed. Input welcome! For reference: Thread starts here: https://lists.freedesktop.org/archives/libreoffice/2024-June/092039.html PPS: Now actually CC'ing the accessibility mailing list as mentioned in my previous email... -- To unsubscribe e-mail to: accessibility+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/accessibility/ Privacy Policy: https://www.documentfoundation.org/privacy
