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 experimentingIt 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.
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
