On 2024-06-11 10:07, Samuel Thibault wrote:
Michael Weghorn, le mar. 11 juin 2024 07:55:47 +0000, 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
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
