On 14/6/24 17:25, Michael Weghorn wrote:
Personal preferences aside, Windows/NVDA as the most widely used
platform indeed generally has some priority for me, as does Writer
over Calc over everything else.
There are other factors I also take into account, though, e.g.
involvement/contributions from others like people working in certain
areas, user requests/tickets, possibilities to cooperate (e.g. the
Orca maintainer reworking Orca's LibreOffice support and providing a
lot of helpful feedback and input) or productivity (my productivity on
Linux is way higher than on Windows, so my take is that putting some
extra initial effort in order to be able to do most of the analysis
for issues *also* affecting Windows on Linux usually pays off, in
particular since the platform APIs IAccessible/AT-SPI2 are fairly
similar).
A further consideration is that, unlike Windows users, Linux users don't
have the option of running Microsoft Office without setting up
virtualization, rebooting the machine to a different environment, or
using a different machine for the purpose. Of course, some Windows users
might not be able to afford it, and they're also an important group to
consider, as are those who prefer the LibreOffice interface.
I personally have access to Microsoft Office as well at the moment, but,
obviously, not in my Linux environment.
I think the problem of disclosing large documents to accessibility APIs
is real and important. I suspect this explains the extraordinary
performance issue that occurs if you try to open a long document in
Microsoft Word for Mac with the VoiceOver screen reader enabled - the
application can be completely unresponsive for several minutes, even on
a fast machine, while the document loads.
My limited understanding of the new protocol proposed for Linux by the
GNOME Foundation is that it is expected to use pipes for data transfer,
giving better performance than DBus calls. So my naive question is: what
would be the performance cost of transferring a large document over the
proposed API? Could it be partly done in the background, so that the
user can at least start to read/edit the document from the top while the
data structures are built and sent to the screen reader?
My assumption is that once the initial transfer is done, all the
remaining updates are incremental, and relatively fast.
Other users may disagree, of course, but from my perspective, having the
application hang while loading a large document would be unacceptable.
However, having to wait a little if I first load a large document, then
jump to the end of it (in the worst-case scenario) would be more
acceptable. Obviously, loading a large document and then immediately
retrieving a list of headings, links etc., is another scenario that
would be subject to potential performance issues. It probably depends on
what the over-all delays are.
--
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
