[libreoffice-accessibility] Re: ESC meeting minutes: 2022-05-26 [IAccessible2 support in JAWS]

[Marco Zehe]

Hi Michael,

AFAIK, QT exposes accessibility information to UIA on Windows. They switched over from an MSAA implementation to UIA some time in the QT5 time frame: https://www.qt.io/blog/2018/02/20/qt-5-11-brings-new-accessibility-backend-windows. So, using QT widgets in the VCL certainly would help with that, UIA implementation bugs in the Windows QT layer not withstanding of course. So, there are advantages of using QT on Windows where appropriate, but that also entails the danger of inheriting QT UIA bugs.

I don't know anything about GTK4, so cannot make any qualified statement.

The original advantages of IAccessible2 and GTK3 was that they were made to be very closely related to one another in terms of concepts. But with GTK4 and other frameworks becoming more prominent, this has only been in a maintained state for years, not really further developed, except for adding necessary missing pieces for new HTML widgets or markup. UIA, on the other hand, has turned out to be much more flexible especially with the latest enhancements published by Microsoft. Custom property sets etc., which allows for various annotations in MS Word, Excel etc. NVDA has a pull request for implementation of some of these newest UIA technologies into their support for MS Office here: https://github.com/nvaccess/nvda/pull/13387

So, in the long run, it is probably safest to indeed invest in switching to an UIA implementation. Note, however, that you may still need to do some work yourselves for the document specific stuff for Writer, Calc, and Impress specifically, since probably not everything is available in the QT libraries that you need.

Marco

-----Original Message-----
From: Michael Weghorn <m.weghorn at posteo.de> 
Sent: Thursday, June 9, 2022 9:01 AM
To: Marco Zehe <marco at marcozehe.de>; accessibility at global.libreoffice.org
Cc: libreoffice-qa at lists.freedesktop.org; libreoffice at lists.freedesktop.org
Subject: Re: [libreoffice-accessibility] Re: ESC meeting minutes: 2022-05-26 [IAccessible2 support in JAWS]


Hi Marco,

On 08/06/2022 13.09, Marco Zehe wrote:
> JAWS does support IAccessible2, but only if it needs to, like in Firefox, and some parts of Chromium-based browsers. However, with the UI Automation implementation for the latter becoming stronger, there might be a time when JAWS moves to UIA for web content support in Chromium browsers. But you never know what plans Vispero actually has for which version of JAWS, ZoomText, and Fusion. All I notice is that, with Windows 11 having an even stronger UIA implementation than 10, more things are being done through that interface rather than traditional MSAA or IAccessible2 channels where possible. And as has been said elsewhere, UIA properties and events are even very accessible from within the JAWS scripting language, which makes this even more compelling because the end user experience can be customized further. As IAccessible2 is an extension of MSAA, and MSAA is largely deprecated by Microsoft, it will probably never get the same treatment.

thanks a lot for that valuable input.

I have added a new sub-section for adding UIA support to the wiki page ( https://wiki.documentfoundation.org/Development/Under-loved_areas#UIA_support_on_Windows
), mostly based on the above and more information from your other email about announcing slide content in Impress presentation mode ( https://listarchives.libreoffice.org/global/accessibility/msg01007.html ).

A probably rather crazy thought I once had was whether it would be a good idea to try to get rid of our custom a11y bridge on Windows in the long run after all, e.g. by switching to Gtk or Qt there as well (at least as one option). But that would certainly have to make sense not only from the a11y perspective but the UI as a whole and would probably be rather contentious.

(I have close to zero knowledge about Windows-specific bits in LO besides winaccessibility, so don't know whether there would be any value in even spending any time in looking into this any further at some point in time. And as of now, neither the gtk4 nor the qt5/qt6 VCL plugins in LO have proper a11y anyway, and the Gtk 4 library presumably doesn't have any a11y implementation for Windows yet either, even though the new a11y architecture [1] in Gtk 4 should allow for one to be added at some
stage.)

Michael

[1] https://blog.gtk.org/2020/10/21/accessibility-in-gtk-4/