97a88e30e2
Add a new class 'AccTableCell' that implements the IAccessibleTableCell interface from the IAccessible2 spec and add what's needed to expose it to accessibility tools via COM. Since there's no specific XInterface for table cells that an XAccessible's context could be queried for, make use of the fact that a table cell's parent is a table, i.e. its accessible context implements XAccessibleTable. AccTableCell keeps a reference to that table and remembers the cell's index in the parent to retrieve information on the cell from there. This addresses the > At least for LibreOffice Table Cells don't implement > IAccessibleTableCell, and therefore there's no way to get the row and > column span. LibreOffice itself also does not expose the merged state in > the accessible name of the cell. comment from [1] (which is the NVDA counterpart for LO's tdf#124832) and may also help for tdf#100086, though more work will be needed on LibreOffice and/or NVDA side for both issues. [1] https://github.com/nvaccess/nvda/issues/9310 Change-Id: I0f53212d14ee17c760b9e6c91be2154a1b25d862 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121821 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> |
||
---|---|---|
.. | ||
inc | ||
source | ||
CustomTarget_ia2_idl.mk | ||
Library_uacccom.mk | ||
Library_winaccessibility.mk | ||
Makefile | ||
Module_winaccessibility.mk | ||
README.md | ||
WinResTarget_uacccom.mk |
Windows Accessibility Bridge
This code provides a bridge between our internal Accessibility
interfaces (implemented on all visible 'things' in the suite: eg.
windows, buttons, entry boxes etc.) - and the Windows MSAA
/
IAccessible2
COM interfaces that are familiar to windows users and
Accessible Technologies (ATs) such as the NVDA screen reader.
The code breaks into three bits:
-
source/service/
- the UNO service providing the accessibility bridge. It essentially listens to events from the LibreOffice core and creates and synchronises COM peers for our internal accessibility objects when events arrive.
-
source/UAccCom/
- COM implementations of the
MSAA
/IAccessible2
interfaces to provide native peers for the accessibility code.
- COM implementations of the
-
source/UAccCOMIDL/
- COM Interface Definition Language (IDL) for UAccCom.
Here is one way of visualising the code / control flow
VCL <-> UNO toolkit <-> UNO a11y <-> win a11y <-> COM / IAccessible2
vcl/ <-> toolkit/ <-> accessibility/ <-> winaccessibility/ <-> UAccCom/
Threading
It's possible that the UNO components are called from threads other
than the main thread, so they have to be synchronized. It would be nice
to put the component into a UNO apartment (and the COM components into STA)
but UNO would spawn a new thread for it so it's not possible.
The COM components also call into the same global AccObjectWinManager
as the UNO components do so both have to be synchronized in the same way.
So we use the SolarMutex
for all synchronization since anything else
would be rather difficult to make work. Unfortunately there is a
pre-existing problem in vcl with Win32 Window creation and destruction
on non-main threads where a synchronous SendMessage
is used while
the SolarMutex
is locked that can cause deadlocks if the main thread is
waiting on the SolarMutex
itself at that time and thus not handing the
Win32 message; this is easy to trigger with JunitTests
but hopefully
not by actual end users.
Debugging / Playing with winaccessibility
If NVDA is running when soffice starts, IA2 should be automatically enabled and work as expected. In order to use 'accprobe' to debug it is necessary to override the check for whether an AT (like NVDA) is running; to do that use:
SAL_FORCE_IACCESSIBLE2=1 soffice.exe -writer
Then you can use accprobe to introspect the accessibility hierarchy remotely, checkout:
http://accessibility.linuxfoundation.org/a11yweb/util/accprobe/
But often it's more useful to look at NVDA's text output window.