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