[libreoffice-accessibility] Re: [a11y] LibreOffice Calc exposes 2^31 children, freezes on `GetChildren`

On 2024-06-12 16:55, Michael Weghorn wrote:
> > > 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 peers we have a similar problem.
> Good point! That could indeed be problematic performance-wise.
>
>
> > > 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 really think that's a mistake that will ultimately hurt ATs 
> > performance and that we should focus on the end-user use-cases we want 
> > to succeed with - rather than having an abstract absolutist 
> > pre-conception that we can expose everything in an efficient way =)
> Sure - if there's a better way to properly make the AT use cases a 
> reality, then let's go that route instead. :-)
One thing that came to my mind is that there's an Action interface (in 
LO and platform a11y APIs) that can be used to provide a set of actions 
that can be triggered by ATs.
This might be usable to provide functionality without having to 
introduce new platform APIs (either permanently, or at least for initial 
prototyping).
I'm wondering whether one potential approach could e.g. be to provide 
different "modes" on how much Writer exposes in the a11y tree, and a way 
to switch between those.
From looking a bit further into NVDA and Orca doc and some experimenting
It seems to me that access to the whole document is needed in particular 
in (1) structural navigation/browse mode, but not (2) focus/editing mode.
If so, one idea might be to only expose the whole document in the a11y 
tree when in read-only "browse mode"/structural navigation mode, not 
when editing the doc.
Screen readers could e.g. explicitly request switching to "expose the 
whole doc" mode when switching to browse mode, and then back to "expose 
only on-screen objects" mode afterwards.
(Alternatively, other variants like explicitly requesting to include 
another page in the a11y tree,... so ATs can work with that could also 
be possible this way.)
Making exposing the whole tree opt-in and only used in read-only mode in 
practice might help address the major performance concerns raised wrt 
re-pagination for now. (The default remains unchanged; ATs can 
explicitly switch, but should then then know what they're doing.)
Or, depending on what exactly is needed for ATs, LO could at least in 
theory even provide navigation actions like "jump to the next 
header/list",... via the Action interface on the a11y layer right away, 
instead of ATs having to implement the logic themselves (and needing 
access to the whole document).
But then, I don't yet see how use cases like "Display a list of all 
headings in the doc" could easily be covered that way.
Just mentioning these thoughts here for now. What's the best way forward 
still needs further consideration/analysis and discussion.
--
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