Date: prev next · Thread: first prev next last


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 +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

PPS: Now actually CC'ing the accessibility mailing list as mentioned in my previous email...

--
To unsubscribe e-mail to: accessibility+unsubscribe@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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.